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ACTICAL  DIVISION  NOTE 


PREFACE 


During  fiscal  1979,  the  Director  of  Program  Integration, 
AF/RDX ,  tasked  ANSER  to  identify  and  develop  a  methodology 
for  allocation  of  funds  among  Air  Force  research,  develop¬ 
ment,  and  acquisition  programs.  This  report,  which  consists 
of  four  volumes  (bound  as  one  document  for  convenience  of  user) , 
describes  work  accomplished  in  response  to  that  tasking  and 
discusses  the  resulting  resource  allocation  methodology  (RAM) . 
Although  RAM  has  been  developed  and  tested  successfully,  our 
experience  to  date  with  its  use  suggests  that  its  future  appli¬ 
cation  will  be  limited  unless  a  method  for  quantitative  evalu¬ 
ation  of  programs  can  be  devised  and  implemented. 
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I .  INTRODUCTION 


This  volume  is  one  of  four  that  document  ANSER's  develop¬ 
ment  of  a  resource  allocation  methodology  (RAM)  for  the 
Director  of  Program  Integration,  AF/RDX.  Each  volume  empha¬ 
sizes  a  particular  aspect  of  our  research  and  can  be  read 
independently  of  the  others.  Volume  1  is  an  overview  of  the 
work  accomplished.  Volume  2  describes  the  RAM  technique 
itself  and  how  to  use  the  general-purpose  computer  programs 
that  incorporate  it.  Volume  3  discusses  how  to  use  the 
interactive  computer  program  developed  for  use  of  RAM  within 
AF/RDX.  Volume  4  reports  on  tests  made  to  determine  the 
computational  performance  of  RAM. 

In  fiscal  1979,  AF/RDX  requested  that  ANSER  conduct  an 
investigation  of  analytic  techniques  that  could  be  used 
to  allocate  resources  and,  if  a  suitable  methodology  was 
found,  we  were  to  develop  it.  The  need  for  such  a  metho¬ 
dology  stems  partially  from  the  large  number  of  program 
elements  (PEs)  that  planners  must  consider.  For  example,  a 
single  budget  could  contain  over  300  PEs,  each  of  which  is 
proposed  at  three  or  four  alternative  funding  levels,  called 
decision  packages.  Each  decision  package,  which  represents 
some  variation  on  the  content  of  the  PE,  contributes  more  or 
less  to  the  achievement  of  associated  objectives.  Objectives 
include  operational  needs  identified  by  Mission  Area  Analysis 
and  other  goals  that  Air  Force  officials  may  establish. 
Furthermore,  the  Program  Objectives  Memorandum  (POM)  is  to 
plan  for  a  5-year  period,  which  means  considering  multiple 
fiscal  constraints.  Therefore,  a  large  number  of  factors 
must  be  considered. 


The  basic  resource  allocation  problem  can  be  stated  as 
two  questions:  At  what  decision  level  should  each  PE  be 
funded  to  achieve  the  greatest  contributions  to  the  specified 
objectives  while  recognizing  fiscal  constraints  over  a  period 
of  several  years?  As  the  availability  of  fiscal  resources 
increases  or  decreases,  how  should  the  investment  strategy  be 
changed  to  maintain  the  greatest  overall  contribution? 

We  believe  we  have  developed  a  unique  and  potentially 
useful  methodology  for  formulation  of  investment  strategies. 
However,  use  of  the  methodology  requires  identification  of 
the  objectives  of  interest  and  evaluation  of  the  contributions 
of  program  alternatives  to  achievement  of  those  objectives. 
Unless  these  requirements  can  be  met  in  a  practical  way, 
application  of  the  methodology  will  be  limited.  AF/RDX  has 
asked  us  to  address  this  problem  in  subsequent  research. 
Chapter  II  of  this  volume  summarizes  our  approach  to  develop¬ 
ment  of  the  methodology.  Chapter  III  describes  how  the 
resource  allocation  methodology  has  been  and  can  be  used.  In 
Chapter  IV,  we  give  our  conclusions  concerning  the  utility  of 
the  methodology  and  discuss  requirements  for  its  further 
implementation . 
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II.  THE  RESOURCE  ALLOCATION  METHODOLOGY 


A.  Our  Approach 

Our  approach  to  the  development  of  a  resource  allocation 
methodology  recognizes  the  multiplicity  of  objectives  that 
must  be  considered  and  their  frequently  conflicting  nature. 
■Furthermore,  the  benefit  from  achievement  of  one  objective 
can  rarely  be  estimated  quantitatively  in  the  same  terms  as 
these  describing  other  benefits.  Therefore,  our  problem  was 
to  develop  a  methodology  that  could  attempt  to  simultaneously 
maximize  several  incommensurable  benefits.  This  approach 
contrasts  with  techniques  that  attempt  to  reduce  the  problem 
to  one  in  which  a  single  benefit  measure  is  used  to  develop 
an  investment  strategy.  One  accepted  single-benefit  tech¬ 
nique  ranks  alternatives  by  their  ratios  of  benefits  and  costs; 
alternatives  are  then  deleted  in  ascending  order  from  the 
bottom  of  the  list  until  the  specified  budget  constraint  is 
no  longer  exceeded.  Unfortunately,  the  aggregate  benefit  of 
the  retained  alternatives  may  not  be  the  largest  obtainable. 
Consider,  for  example,  the  four  alternatives  in  Table  1,  which 
we  ranked  in  order  of  benefit/cost  ratio.  At  a  sample  budget 
of  18  units,  only  the  first  two  projects  could  be  funded  for 
a  total  benefit  of  9.  However,  if  the  third  is  substituted 
for  the  first,  the  cost  of  17  would  be  within  the  allowable 
budget  and  the  benefit  is  10,  a  number  greater  than  the 
original  allocation. 

A  second  problem  exists  with  use  of  a  single  benefit/cost 
ratio  if  the  cost  is  obtained  by  summing  multiyear  costs, 
since  infeasible  cost  profiles  could  easily  result.  In  other 
words,  the  sum  of  the  costs  of  the  projects  in  an  R&D  pro¬ 
gram  may  not  violate  the  sum  of  the  fiscal  constraints  in 
various  years,  but  in  a  given  year,  those  costs  could  indeed 
violate  the  fiscal  constraints. 
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TABLE  1 

SAMPLE  ALTERNATIVES  BY  BENEFIT/COST  RATIO 


Alternative 

Cost 

Benefit 

Benefit/Cost 

Cumulative  Cost 

1 

8 

6 

3/4 

8 

2 

5 

3 

3/5 

13 

3 

12 

7 

7/12 

25 

4 

15 

5 

1/3 

40 

B .  The  Allocation  Methodology 

The  resource  allocation  methodology  that  we  selected  after 
investigation  of  several  techniques  employs  goal  programming. 
Use  of  the  technique  requires  definition  of  a  set  of  goals 
and  their  classification  into  subsets  having  different  prior¬ 
ities  for  achievement.  For  example,  as  a  class,  operational 
goals  may  be  afforded  a  higher  priority  than  that  afforded 
programmatic  goals.  Furthermore,  goals  within  each  subset 
will  usually  differ  in  importance.  Consequently,  the  im¬ 
portance  of  each  goal  within  every  subset  must  be  specified. 
Specification  of  the  relative  priorities  of  the  subsets  and 
the  relative  importance  of  the  goals  in  each  subset  permits 
use  of  a  priority  goal  structure  for  development  of  an  invest¬ 
ment  strategy.  This  procedure  always  finds  the  investment 
strategy  that  most  closely  satisfies  the  first-priority  goals. 
The  procedure  then  attempts  to  satisfy  the  second-priority 


goals  without  degrading  the  achievement  of  first-priority 
goals.  This  process  continues  for  all  successive  priority 
levels.  (See  Volume  2  for  additional  explanation  of  the 
process . ) 

This  procedure  adequately  represents  all  important  aspects 
of  the  allocation  process.  It  provides  substantial  flexibility 
in  its  representation  of  the  preferences  of  the  decision-maker 
and  in  its  recognition  of  the  complex,  multigoal  nature  of 
the  decision.  Through  use  of  the  priority  goal  structure 
most  practical  considerations  can  be  represented.  A  need  to 
comply  with  agreements  to  pursue  certain  programs  can,  for 
example,  be  represented  as  a  Priority  1  goal.  Goals  not 
quantifiable  in  the  same  terms  can  be  represented  on  different 
priority  levels,  which  precludes  any  need  to  compare  "apples 
and  oranges".  Any  type  of  goal  can  be  incorporated  into  the 
structure  as  long  as  the  user  of  the  method  can  evaluate  the 
alternatives  with  respect  to  it. 

We  selected  an  algorithm  for  determination  of  the  preferred 
investment  strategy  that  is  an  adaptation  of  a  technique  de¬ 
veloped  by  Petersen.^  It  ranks  the  alternatives  according 
to  an  average  benefit/cost  ratio  and  then  improves  the 
solution  by  examining  various  exchanges  between  the  unfunded 
alternatives  and  those  initially  funded.  In  other  words,  it 
finds  a  workable  solution  and  proceeds  systematically  to  im¬ 
prove  it.  (See  Volume  2  for  complete  description  of  the 
algorithm. ) 


^Petersen,  Clifford  C. ,  "A  Capital  Budgeting  Heuristic 
Algorithm  Using  Exchange  Operations,"  AIIE  Transactions , 
VI,  2  June  1974. 


The  technique  does  not  examine  all  possible  combinations  of 
alternatives.  Instead,  it  uses  deductive  rules  to  eliminate 
combinations  that  need  not  be  considered,  realizing  substantial 
efficiency.  Observe  that  the  algorithm  begins  with  the  type 
of  strategy  that  results  from  the  techniques  discussed  in 
Section  II. A  and  then  improves  it. 

C.  Computer  Implementation 

We  wrote  two  types  of  computer  programs  to  solve  resource 
allocation  problems.  The  first  type  consists  of  general- 
purpose  representations  of  the  methodology,  called  RAM/GP 
and  RAM/VM.  RAM/GP  and  RAM/VM  could  be  used  with  any  kind 
of  resource  allocation  problem  for  which  data  are  available. 
RAM/GP  contains  the  methodology  described  in  the  previous 
section  in  which  the  user  wishes  to  come  as  close  as  possible 
to  the  specified  goals.  In  some  cases,  however,  the  user 
cannot,  or  may  not  want  to,  specify  an  explicit  objective 
value  as  a  goal.  The  user  may,  instead,  simply  wish  to 
maximize  the  contributions  made  to  all  goals,  which  is  possible 
using  RAM/VM.  This  form  is  equivalent  to  the  previous  one  in 
which  goals  are  simply  set  at  unreachable  levels.  In  fact, 
both  programs  would  find  the  same  solution.  However,  use  of 
RAM/VM  can  be  more  efficient  if  the  less  complex  data  it 
requires  are  available.  Volume  2  describes  both  RAM/GP  and 
RAM/VM. 

The  second  type  of  program  is  a  special-purpose  program. 

It  consists  of  RAM/VM  imbedded  in  a  larger,  user-interactive 
program,  and  was  designed  to  demonstrate  the  day-to-day  use 
of  the  method  by  those  responsible  for  formulating  investment 
strategies.  The  methodology  is  tied  to  the  program  element 
(PE)  data  base  used  by  AF/RDX.  By  operating  a  computer  ter¬ 
minal,  a  user  obtains  access  to  the  data  for  the  programs 
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for  which  he  has  responsibility  (and  only  those  programs) . 

Then  by  following  simple  procedures  in  response  to  prompting  by 
the  computer,  the  user  can  specify  alternative  budgets  for 
any  number  of  years  desired  and  receive,  usually  in  seconds, 
the  alternatives  to  be  funded  that  represent  the  best  invest¬ 
ment  strategy.  If  he  generates  alternative  strategies  in 
response  to  revised  fiscal  constraints,  the  results  are 
accumulated  and  displayed  in  the  form  of  cost/benefit  curves. 
Hard  copies  of  the  curves  are  available  as  soon  as  the  plots 
are  made.  The  program  is  special  purpose  because  it  was 
designed  for  the  type  of  hardware  available  at  the  AF/RDX 
computer  site  (Multics  computer  system)  and  was  tied  to  the 
official  PE  data  base  as  it  existed  in  fiscal  1979.  It  demon¬ 
strates  the  ease  with  which  the  methodology  can  be  used  to 
examine  the  impacts  of  enhanced  or  decremented  budget  ceilings 
on  the  investment  strategies.  By  front  loading  (shifting 
funds  to  earlier  periods)  or  back  loading  (shifting  funds  to 
later  periods) ,  the  user  can  examine  the  impact  of  the  resul¬ 
tant  investment  strategies  in  terms  of  the  impact  of  the 
progress  made  toward  selected  goals.  Such  excursions  make 
the  methodology  useful  for  multiperiod  planning  on  a  quick- 
turnaround  basis.  We  describe  this  computer  program  in 
Volume  3. 

We  tested  the  performance  of  these  programs  in  a  process 
described  in  Volume  4,  examining  both  the  solution  accuracy 
of  the  programs  and  the  time  required  to  solve  problems  of 
various  sizes.  However,  because  our  methodology  is  so  much 
more  efficient  than  other  available  techniques,  it  was  difficult 
to  get  a  standard  for  judging  the  performance  of  our  programs. 
Testing  of  this  kind  is  very  expensive,  and  in  many  cases,  the 
only  available  commercial  routine  we  could  use  to  establish  a 


solution  failed  to  reach  a  solution  in  a  practical  time.  RAM/ 
GP  provides  practical  solution  times  (on  the  order  of  a  few 
minutes)  for  problem  sizes  of  200  to  250  decision  variables 
(possible  alternatives) ,  while  RAM/VM  provides  practical  so¬ 
lution  times  for  larger  problems.  The  practical  problem  size 
limitation  of  the  commercial  routine  was  an  order  of  magnitude 
less  and  restricted  our  comparison  tests  to  smaller  problems 
of  approximately  45  variables.  For  problems  of  this  size, 
statistical  analysis  indicates  a  reasonable  degree  of  con¬ 
fidence  that  RAM  results  are  optimal  or  near  optimal.  We 
believe  that  the  accuracy  of  results  will  hold  for  even  larger 
problems,  although  we  have  no  statistical  basis  for  that  be¬ 
lief. 
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III.  APPLICATIONS  OF  THE  METHODOLOGY 


A.  Large-Scale  Application 

We  have  been  unable  to  apply  the  methodology  on  a  large- 
scale  primarily  because  no  institutionalized  procedures  exist 
within  Headquarters  USAF  for  making  quantitative  evaluations 
of  R&D  alternatives.  Although  at  the  outset  of  our  work  some 
attempts  to  formulate  and  institutionalize  such  a  process 
had  been  made,*  the  process  no  longer  exists. 

B .  Special-Purpose  Applications 

RAM  has  been  used  for  allocating  resources  in  a  number  of 
special  purpose  applications.  The  methodology  has  been  trans¬ 
ferred  to  computers  at  the  Aeronautical  Systems  Division  (ASD) 
where  it  has  been  used  in  a  pilot  study  of  avionics  R&D  pro¬ 
grams,  and  where  it  will  be  used  to  allocate  resources  among 
aeropropulsion  R&D  programs. 

We  have  also  used  RAM  within  Hq  USAF  to  assist  in  the 
development  of  an  armament  functional  area  plan.  This  func¬ 
tional  area  cuts  across  four  mission  areas:  counterair, 
close  air  support/battlefield  interdiction,  defense  suppression, 
and  interdiction.  We  derived  goals  from  appropriate  Mission 
Area  Analysis  tasks,  e.g.,  targets  of  various  types  to  be 
destroyed  in  various  weather  conditions.  These  goals  com¬ 
prised  the  first  priority  level  and  were  assigned  the  relative 
importance  identified  in  the  MAA  process.  We  also  identified 
a  single  goal  at  the  second-priority  level,  namely  to  decrease 

♦This  process  is  described  in  "Mission  Area  Resource  Alloca- 
tion  for  Air  Force  R&D,"  Defense  Systems  Management  Beviev , 

Volume  2,  Spring  1979, 
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procurement  spending  where  possible  by  competitive  bidding. 
This  goal  consumes  R&D  resources  to  fund  multiple  contractor 
involvement  in  parallel  RDT&E  efforts. 

We  formulated  funding  alternatives  that  were  associated 
with  a  unique  set  of  products  (armament  systems  or  subsystems) 
completion  dates,  risk  factors,  and  cost  elements  of  the 
decision  package  sets  for  the  19  program  elements  in  the 
functional  area. 

We  determined  the  impact  of  each  product  on  the  ability 
of  the  Air  Force  to  meet  the  specified  operational  goals 
using  a  linear  measure  of  increase  in  force  effectiveness. 
Then,  this  contribution  was  enhanced  or  degraded,  depending 
on  the  timeliness  of  the  product,  in  meeting  the  threat  and 
the  technical  risk  involved  in  developing  the  product. 

Summing  the  contributions  of  the  products  of  each  funding 
alternative  provided  a  linear  index  of  value  for  each  funding 
alternative.  We  then  introduced  the  procurement  savings 
(if  any)  produced  by  a  funding  alternative  as  a  second- 
priority  goal. 

We  made  a  number  of  RAM  runs  representing  excursions  on 
budget  ceilings,  and  benefit/cost  curves  were  produced.  Re¬ 
sults  to  date  have  been  well  accepted  by  the  tasking  office. 
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IV.  CONCLUSIONS 


The  resource  allocation  methodology  (RAM)  that  we  de¬ 
veloped  can  be  used  in  the  formulation  of  R&D  investment 
strategies  (if  a  practical  process  for  evaluation  of  alter¬ 
natives  can  be  devised)  and  in  any  type  of  resource  alloca¬ 
tion  decision  that  must  choose  among  discrete  alternatives. 

We  believe  that  RAM  is  a  unique  technique  that  can  reflect 
the  significant  aspects  of  most  allocation  decisions.  We 
know  of  no  other  technique  that  formulates  and  solves  the 
allocation  problem  in  the  same  manner  as  that  used  in  RAM. 

RAM  can  be  refined  and  extended  in  several  ways.  For 
example,  additional  work  could  produce  a  general-purpose 
interactive  program  of  the  type  demonstrated,  but  which  allows 
the  user  to  work  with  more  of  the  data  base  than  the  fiscal 
constraints,  e.g.,  to  interactively  change  goals  or  costs 
and  evaluations  of  the  alternatives.  Also,  an  output  pro¬ 
cessor  should  be  developed  to  interpret  the  changes  in  results 
when  running  excursions  on  the  budget  ceilings.  Such  a 
processor  would  highlight  the  impact  on  the  goals  that  results 
when  running  such  excursions.  These  are  essentially  data 
management  or  bookkeeping  improvements,  but  they  would  en¬ 
hance  the  utility  of  the  method. 

Also,  while  the  RAM  programs  are  sufficiently  accurate 
and  efficient  for  the  problems  we  envision,  further  research 
could  possibly  provide  some  improvements  in  efficiency  if 
improved  efficiency  is  required.  We  have  found  one  technique 
that  could  improve  efficiency,  but  a  major  development  and 
test  program  would  be  required  to  verify  its  potential.  An 
improvement  in  efficiency  could  increase  the  effective  pro¬ 
blem  size  of  RAM. 
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Such  improvements  are  of  second-order  importance;  however, 
the  most  significant  problem  in  wide-scale  use  of  RAM  is  the 
lack  of  a  procedure  for  evaluating  alternatives.  If  it  is 
feasible  to  develop  and  implement  such  a  procedure,  we  will 
then  be  able  to  provide  the  decision-maker  with  an  assurance 
that  the  best  possible  strategy  with  respect  to  the  specified 
goals  has  been  identified.  This  strategy  will  certainly  not 
replace  the  decision-maker;  rather,  it  will  assist  him  by 
providing  a  strategy  reflecting  those  considerations  chosen 
for  explicit  representation.  It  will  provide  the  decision¬ 
maker  with  more  time  to  review  the  resource  allocation  and, 
perhaps,  to  improve  it  further  by  applying  his  own  expertise 
on  matters  that  have  not  been  explicitly  assessed. 
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I.  INTRODUCTION 


This  volume  is  one  of  four  that  document  ANSER's  de¬ 
velopment  of  research  and  development  (R&D)  resource  allo¬ 
cation  methodology  (RAM)  for  the  Director  of  Program 
Integration,  AF/RDX.  Volume  1  summarizes  the  work  and  its 
applications.  Volume  2  describes  the  RAM  technique  and 
how  to  use  the  computer  programs  that  incorporate  it. 

Volume  3  describes  additional  software  developed  to  demon¬ 
strate  the  RAM  technique,  and  Volume  4  describes  the  way  in 
which  we  tested  the  computational  capability  of  the  RAM  pro¬ 
grams.  Each  volume  emphasizes  a  particular  aspect  of  our 
research  and  can  be  read  independently  of  the  others . 

This  volume  concentrates  on  the  technique  we  adopted  to 
solve  the  resource  allocation  problem  and  the  associated  com¬ 
puter  programs.  In  Chapter  II,  we  describe  what  the  computer 
programs  do  in  a  mathematical  sense,  and  in  Chapter  III  we 
describe  how  to  use  them.  The  reader  who  is  not  interested 
in  the  underlying  technical  process  can  probably  bypass 
Chapter  II  and  apply  the  programs  using  only  the  discussion 
contained  in  Chapter  III.  However,  some  knowledge  of  com¬ 
puter  programming  and  mathematics  is  necessary.  Chapter  IV 
contains  the  computer  codes  for  these  programs. 

In  the  discussion,  we  frequently  use  the  vocabulary  of 
the  R&D  resource  allocation  problems  for  which  we  developed 
the  technique.  However,  the  procedure  and  computer  programs 
are  applicable  to  a  wide  range  of  mathematical  optimization 
problems  as  described  in  Chapter  II.  Although  the  reader 
may  have  to  translate  our  vocabulary  to  that  of  his  problem, 
we  hope  that  this  volume  can  be  used  as  a  manual  for  other 
applications. 


II.  THE  RESOURCE  ALLOCATION  MODEL 


In  this  chapter,  we  describe  the  role  of  the  RAM 
(Resource  Allocation  Methodology)  computer  programs.  The 
discussion  is  necessarily  technical.  The  reader  who  is  not 
technically  inclined  can  omit  this  chapter  if  he  wishes 
merely  to  apply  the  technique,  although  a  scan  of  at  least 
the  first  part  of  Secion  II. A,  which  describes  our  model 
of  the  decision  process,  is  recommended.  Section  II. B 
contains  a  summary  of  the  central  RAM  algorithm. 

A.  Mathematical  Formulation  of  the  Problem 

In  the  RAM,  the  decision  process  involved  in  allocating 
resources  is  modeled  as  a  mathematical  optimization  problem: 
the  packing  problem.  This  problem  can  be  explained  with  a 
physical  analogy  in  three  dimensions.  Imagine  a  large  box 
that  must  hold  a  number  of  smaller  boxes  of  varied  sizes. 

Each  small  box  has  an  associated  measure  of  value,  and  not 
all  the  small  boxes  will  fit  simultaneously  in  the  large  box. 
The  problem  is  to  pack  the  large  box  so  that  the  total  value 
of  small  boxes  contained  within  is  maximized.  The  three 
dimensions  of  this  problem  correspond  to  the  length,  width, 
and  depth  of  the  large  box.  Note  that  each  small  box  uses 
up  some  of  each  of  these  dimensions.  In  the  R&D  resource 
allocation  problem,  for  example,  the  number  of  budget  periods 
considered  corresponds  to  the  dimensionality  of  the  associat¬ 
ed  packing  problem.  Each  R&D  project  alternative  (or  each 
small  box)  potentially  uses  up  some  amount  in  each  budget 
period  and  some  associated  measure  of  benefit.*  The  problem 

*See  Volume  1  for  a  discussion  of  benefit  measures  and  other 

aspects  of  this  problem. 
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then  becomes  to  maximize  the  total  benefits  subject  to  the 
budget  constraints. 

This  model  of  the  decision  process  has  three  main  com¬ 
ponents.  First,  there  is  a  set  of  discrete  alternatives 
that  must  be  selected  on  a  yes  or  no  basis.  They  are 
represented  by  decision  variables  whose  values,  typically 
0  or  1,  correspond  to  nonselection  and  selection,  respective¬ 
ly.  The  solution  algorithm  determines  these  values.  Second, 
there  is  an  index  representing  the  degree  of  effectiveness 
that  results  when  a  particular  alternative  is  selected. 
Finally,  there  is  a  measure  of  the  resources  that  must 
be  consumed  in  any  dimension  (such  as  budget  periods)  to 
accrue  these  benefits.  We  normally  refer  to  the  resource 
consumption  as  a  "cost",  although  these  resources  may  not 
be  dollars. 

The  basic  multidimensional  packing  problem  can  be  further 
defined  as  follows: 

Let  Z  represent  the  total  achieved  system  effectiveness 
(benefit) 

n 

Maximize  Z  =  Z  A .  X . 

i-1  1  1 

Subject  to: 

n 

I  C.  .  X.  <  b.  j~l , . . . , M 
i=l  13  1  3 

Xi  e  |o-l{  Vi 

where : 

X^  is  a  decision  variable  taking  on  a  value  of  1 

if  the  ith  option  is  in  the  solution,  and  0 
otherwise . 
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A.  is  the  effectiveness  index  (a  linear  mea- 
i  sure  of  benefit)  of  the  ith  option. 

C. .  is  the  cost  of  the  ith  option  with  respect 
1"'  to  the  jth  dimensional  constraint. 

b.  is  the  maximum  amount  of  resources  avail- 
^  able  in  the  jth  dimension. 

In  many  cases,  this  would  be  a  satisfactory  representa¬ 
tion  of  a  resource  allocation  decision  process.  However, 

for  R&D  end  perhaps  many  other  resource  allocation  problems, 

# 

the  decision  is  substantially  more  complex  because  it  must 
be  made  with  respect  to  many  objectives  or  goals.  Further, 
the  decision-maker  may  decide  that  some  goals  have  a  higher 
priority  than  others.  To  reflect  these  very  real  complexi¬ 
ties,  we  extended  the  multidimensional  packing  problem. 

Suppose  system  performance  must  be  measured  against  Mr 
objectives  (goals)  of  which  goals  1  to  M1  are  in  the  first 
priority  level,  goals  (M1  +  1)  to  M2  are  in  the  second  pri¬ 
ority  level,  and  so  on.  First-priority  goals  must  be 
satisfied  as  far  as  possible  before  other  goals  can  be  satis¬ 
fied.  Furthermore,  goals  at  the  second  priority  level  can 
be  satisfied  only  if  their  satisfaction  does  not  degrade  the 
already  achieved  goals  and  so  on  down  the  line.  Each  priority 
level  comprises  a  vector  element  in  the  achievement  function. 
Thus  we  write: 


Minimize  Z  = 


Subject  to: 


1  (W' 

k=l  K 


WkNk 


(r-1 ) 


AikXi  +  Nk  "  Gk 


k=l , . . . ,M 


n 


X.  e  (0-1) 
1 


<  b  . 

-  I 


Vi 


j  =  l  > 


,M 


where : 

X-  is  a  decision  variable  taking  on  a  value 

1  of  1  if  the  ith  option  is  in  the  solution, 

and  0  otherwise. 

A.  is  the  effectiveness  index  of  the  ith 
1  option  relative  to  the  kth  goal. 

G,  is  the  desired  effectiveness  against  the 
K  kth  goal.  Gk  >  0 

are  negative  deviation  variables  indicat¬ 
ing  the  amount  by  which  a  solution  fails 
to  satisfy  the  kth  goal. 

W  is  the  weight  (relative  importance)  attached 
to  satisfying  the  kth  goal.  These  can  be 
viewed  as  penalty  factors.  If  we  fall  short 
of  the  kth  goal  by  2  units,  the  associated 
element  in  the  achievement  vector  (to  be 
minimized)  is  increased  by  2  units. 

Cj.  is  the  cost  of  the  ith  option  in  the  jth 
3  dimension  (e.g.,  budget  period). 


This  formulation,  called  goal  programming,  is  distin¬ 
guished  by  the  form  of  the  objective  function,  which  minimizes 
the  deviation  from  specified  goals.  It  also  contains  a  set 
of  weighting  factors,  {  }  ,  which  allow  the  goals  on  each 

priority  level  to  be  given  a  relative  importance. 

It  is  not  always  desirable  or  possible  to  specify  ex¬ 
plicit,  quantitative  goals.  Instead,  one  may  simply  wish  to 
find  the  resource  allocation  that  maximizes  the  contributions 
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of  the  chosen  alternatives  with  respect  to  all  the  goals. 

This  is  equivalent  to  the  previous  formulation  in  which  all 
the  goals  have  been  set  to  a  level  higher  than  that  obtain¬ 
able;  that  is,  where; 

G  >E  AikXi  k=1 . Mr 

K  i=l 

This  method  is  called  a  vector  maximization  formulation  of  the 
decison  process. 

Goal  programming  and  vector  maximization  formulations 
are  fundamentally  related,  and  so  their  respective  programs, 
RAM/GP  (goal  programming)  and  RAM/VM  (vector  maximization) , 
are  very  nearly  the  same.  The  solution  algorithms,  the 
means  of  determining  the  X^,  are  the  same.  We  simply  obtain 
certain  efficiencies  in  using  RAM/VM  by  recognizing  in 
advance  when  a  maximization  model,  rather  than  one  in  which 
explicit  goals  are  required,  is  the  best  model  of  the  decision 
process . 

One  additional  refinement  of  the  decison  process  is  in¬ 
corporated  in  both  RAM/GP  and  RAM/VM.  The  subsets  that 
contain  mutually  exclusive  alternatives  are  incorporated  in 
the  solution  procedure.  In  other  words,  alternatives  may 
be  formed  into  groups,  and  no  more  than  one  can  be  in  the 
solution.  This  arrangement  models  the  case  in  which  the 
decision  is  to  determine,  for  many  programs,  which  of 
several  predefined  alternatives  should  be  selected. 

B.  Solution  Algorithm 

The  decision  models  chosen  can  be  adapted  to  various  so¬ 
lutions  by  a  wide  range  of  integer  programming  techniques. 

In  this  class  of  problems,  however,  the  analyst  must  choose 
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an  acceptable  tradeoff  between  true  optimal  solutions,  pro¬ 
blem  size,  and  run-time  considerations.  Very  often,  a  search 
for  a  true  optimal  solution  using  one  of  the  classical  in¬ 
teger  programming  techniques  results  in  impractical  computer- 
resource  requirements  for  a  problem  of  any  real  size.  The 
technique  employed  in  RAM  to  solve  the  goal  programming  and 
vector  maximization  packing  problems  previously  defined  is 
based  on  a  variant  of  the  direct-search  technique  developed 
by  Clifford  Petersen  at  Purdue  University.'1'  Petersen's 
method  performs  to  well  within  the  margin  of  data  uncertainty 
for  the  R&D  resource  allocation  problem  we  addressed,  while 
allowing  large  problems  to  be  solved  relatively  quickly  with 
very  small  demands  on  computer  hardware  resources.  (See 
Volume  4  for  details  on  the  results  of  a  series  of  test 
runs  made  to  ascertain  RAM  performance  characteristics  rela¬ 
tive  to  certain  other  techniques.) 

The  steps  for  completing  the  RAM/GP,  RAM/VM  algorithm  are 
as  follows: 


1. 


Compute  for  each  R&D  alternative  i,  its  mean  proportionate 
demand  on  budget  funds ,  R, ,  where 

m 


^  c^/bJ 

m 


2. 


Compute  the  relative  independent  benefit/cost  ratio  vec¬ 
tor  for  each  alternative,  AH,,  where 


AH,  = 


M 


K=1 


K  ik 1 


Ri 


M^ 


K=M(n-l)+1 


W„  A., 
K  ik 


Ri 


Petersen,  Clifford  C.,  "A  Capital  Budgeting  Heuristic  Al¬ 
gorithm  Using  Exchange  Operations,"  AIIE  Transactions ,  VI, 
2,  June  1974. 
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3.  Pick  for  each  alternative  group  (subset  of  mutually 
exclusive  alternatives)  the  R&D  alternative  with  the 
highest  value  5T  .  Place  these  alternatives  in  the 
"in"  set.  Rank  in  descending  order  of  AH^  values. 

Place  the  remaining  alternatives  in  the  "out"  set. 

4.  Delete  alternatives  from  the  bottom  of  the  "in"  set 
until  budgets  are  not  exceeded  in  all  budget  periods. 
Place  deleted  alternatives  in  the  "out"  set.  If  problem 
requires  vector  maximization  formulation  go  to  5a.  If 
problem  requires  goal  programming  formulation  go  to 

5b. 

5a.  Compute  =  AIL*  R^  for  all  alternatives.  Rank  the 
"in"  set  in  order  of  increasing  values.  Rank  the 
"out"  set  in  order  of  decreasing  A^  values. 

6a.  Subject  to  dominance  rules  deriving  from  the  ranking, 
find  the  best  exchange  (2-for-l  or  1-for-l)  between 
the  "out"  set  and  the  "in"  set.  If  no  such  exchange 
improves  the  solution,  go  to  step  8.  (Exchanges  must 
preserve  budget  feasibility) . 

7a.  Rerank  the  new  "in"  and  "out"  sets  as  in  steps  5a  and 
6a . 

8a.  If  any  funds  are  left,  try  to  include  some  level  of 
any  unfunded  alternative.  This  is  called  "Fitback" . 

9a.  STOP 

5b.  Compute  provisional  achievement  of  goal  k?  gk  for  all 
goals.  For  each  variable  in  the  solution  at  the  Pri¬ 
ority  1  level,  compute  A^»  the  contribution  of  variable 
i  to  the  satisfaction  of  goal  k. 
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let  Qik  =  max  (0,(aik  +  Gk  "  9k)5 


then  let  Aik  =  min  (aik,  Qik) 


Then  compute  the  total  weighted  contribution  of  variable 

i;  ft.  for  the  variables  in  the  solution 
1 


A .  =  E 
1  k=l 


Vik 


(r-1 ) 


Rank  the  "in"  set  in  order  of  increasing  A^  values. 

Subject  to  a  weakened  set  of  dominance  rules,  find  the 
best  exchange  (2-for-l  or  1-for-l)  between  the  "out" 
set  and  the  "in"  set.  To  test  an  exchange  for  pro¬ 
fitability,  remove  the  "in"  set  variable (s)  in  its 
solution,  insert  the  "out"  set  variable (s)  in  its 
place,  and  an  ft.  value  for  the  new  variables  as  was 
done  in  step  5.  Compare  ft^s.  (Exchanges  must  main¬ 
tain  budget  feasibility.)  If  no  profitable  exchange 
is  found,  go  to  step  8b. 

Go  to  step  5b. 

If  any  funds  are  left,  try  to  include  some  level  of 
any  unfunded  alternative  (Fitback) . 

STOP 


III.  USING  THE  COMPUTER  PROGRAMS 


In  this  section,  we  describe  how  to  use  the  RAM/VM  and 
RAM/GP  computer  programs.  These  programs  solve  a  resource 
allocation  problem  with  multiple,  prioritized  objectives 
in  which  constraints  are  placed  on  resource  use  over  time. 
RAM/VM  selects  the  set  of  alternatives  that  maximizes 
the  contributions  toward  the  objectives  within  resource 
limitations.  Most  of  our  experience  to  date  has  been  with 
RAM/VM  because  of  its  easy  application  to  existing  data. 
Consequently,  we  devote  most  of  the  discussion  to  this 
formulation.  Because  RAM/GP  is  used  in  a  very  similar  fash¬ 
ion,  we  confine  our  discussion  of  this  formulation  to  the 
areas  in  which  it  differs  from  RAM/VM. 

These  programs  are  described  as  being  in  a  free-standir.c 
mode,  which  we  used.  They  are  easily  imbedded  in  an  inter¬ 
active  program  for  repetitive  use.  In  fact,  we  have  done 
this  with  RAM/VM  to  demonstrate  the  process.  However, 
because  this  demonstration  program  is  useful  only  on  a  par¬ 
ticular  computer  and  with  particular  terminals,  it  is 
described  in  Volume  3.  RAM/VM  and  RAM/GP  are  more  general. 
They  have  been  coded  in  FORTRAN  for  use  on  the  Multics 
computer  system,  as  installed  on  the  Honeywell  Series  68/ 
Level  60  computer.  Modifications  to  the  coding  may  be  re¬ 
quired  in  the  input/output,  load/compile,  and  execute  job 
control  language  for  use  on  other  computing  systems. 

A.  Guide  to  RAM/VM 

1 .  The  Resource  Allocation  Problem 

The  RAM/VM  program  is  designed  to  assist  the  decision¬ 
maker  in  allocating  resources  to  alternatives  in  cases  where 
more  alternatives  exist  than  can  be  supported  by  available 
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resources.  Although  the  problem  is  quite  general,  we  can 
describe  it  in  terms  of  an  R&D  project  selection  problem. 

Each  element  of  the  R&D  program  can  be  selected  at  no  more 
than  one  of  a  number  of  predefined,  alternative  funding 
levels.  Each  funding  level  consumes  a  different  amount  of 
resources  (dollars)  in  each  of  several  budget  periods  and 
results  in  outputs  that  differ  in  the  benefits  received. 
Benefits  reflect  the  contribution  of  each  alternative  to 
each  objective.  Benefits  measured  by  the  user  are  used  as 
inputs  to  this  computer  program.  The  objectives  of  the  re¬ 
source  allocation  process  must  be  organized  into  one  or  more 
prioritized  groups.  Within  a  group,  a  relative  weighting  of 
the  objectives  may  be  specified,  for  example,  in  order  of 
their  relative  importance.  Finally,  resource  constraints 
must  be  specified  for  as  many  budget  periods  as  exist,  and 
the  cost  of  each  alternative  in  each  period  must  be  provided. 

RAM/VM  uses  a  ranking  technique  in  Phase  1  to  obtain  an 
initial  feasible  solution  and  then  in  Phase  2,  tries  to  im¬ 
prove  this  initial  solution  through  a  series  of  exchange 

operations.*  This  approach  is  based  on  Petersen's  Capital 

2 

Budgeting  Heuristic  Algorithm.  The  program  attempts  to 
maximize  (with  no  upper  limit)  the  total  achievement  value 
of  all  objectives  at  each  priority  level.  The  Priority  1 
objectives  are  maximized  first,  and  the  objectives  associated 
with  each  successive  priority  level  (if  any  exist)  are  then 
maximized  if  the  achievement  of  preceding  higher  level  ob¬ 
jectives  is  not  degraded.  To  maximize  the  objectives,  RAM/VM 

- - - - - - 

Petersen,  Clifford  C.,  "A  Capital  Budgeting  Heuristic 
Algorithm  Using  Exchange  Operations,"  AIIE  Transactions , 

VI,  2,  June  1974. 

♦See  Section  II. B  for  description  of  ranking  and  exchange 
techniques . 
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selects  no  more  than  one  alternative  from  each  group  (mutually 
exclusive)  such  that  the  total  measurable  benefit  (at  each 
priority  level)  is  maximized  (subject  to  the  availability  of 
required  resources) .  The  alternatives  are  assigned  a  value 
of  1  if  included  in  the  solution,  0  if  not. 

2 .  Data  Input 

RAM/VM  uses  formatted  READ  statements  to  input  data  from 
a  file  assigned  to  logical  unit  10.  Table  1  identifies  the 
required  input  to  RAM/VM  and  the  corresponding  data  formats. 

A  brief  description  of  each  data  item  is  also  included. 

Note  the  flag,  IGS.  This  flag  is  set  equal  to  1  if 
some  alternative  group  exists  that  must  be  represented  in  the 
solution.  For  the  mutually  exclusive  alternative  groups, 
which  require  that  no  more  than  one  alternative  be  selected, 
the  IGS  set  equal  to  1  will  require  that  exactly  one  alter¬ 
native  be  selected  from  each  alternative  group  contained 
in  the  Priority  1  objective.  This  Priority  1  objective 
must  be  of  the  form:  Maximize 

1  Ai  Xi  ' 

l 

where  A^  is  set  equal  to  1  for  alternative  i  if  its  associated 
alternative  group  must  be  included  in  the  solution,  and  A^  is 
set  equal  to  zero  otherwise.  Additional  comments  on  the  use 
of  IGS  are  provided  in  Section  III. A. 4. 

3 .  Solution  Output 

The  output  from  RAM/VM  is  stored  in  a  file  assigned 
to  logical  unit  8  in  a  sequential  format.  "FILEOUT"  is  the 
name  assigned  to  the  output  file  by  RAM/VM  as  currently 
implemented  on  Multics. 
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TABLE  1 

INPUT  DATA  FORMATS  FOR  RAM/VM  AND  RAM/GP 


Card 

Data 

Format 

Description 

Comments 

1 

15 

The  number  of  0-1  variables 
(total  of  all  alternatives) 

jl  KM 

15 

The  number  of  objectives 

15 

The  number  of  priority  levels 

NPEF! 

15 

The  number  of  budget  periods 

NGR 

15 

The  number  of  mutually  exclusive 
alternative  groups 

IGS 

15 

A  flag,  when  set  to  1  indicates  the 
presence  of  alternative  groups  that 
must  be  funded  at  a  nonzero  level 

2  -  a 

W(J) 

15 

The  weighting  factor  associated 
with  objective  J 

Input  as  (W(J),  PR(J),J  =  1,NG) 

PR(J) 

15 

The  priority  level  that  includes 
objective  J 

(a  +  1)  -  b 

CO.  L) 

10F8.0 

The  cost  of  variable  1  in 
budget  period  1 

For  each  budget  period  1,  input 
as  (C(l,  1),  1  =1,  NVAR) 

(b  +  1)  -  c 

IGR(I) 

1615 

The  alternative  group  that 
contains  variable  1 

Input  as  (IGR(I),  1  =  1,  NVAR) 

(c  +  1)  -  d 

ILEV(I) 

1615 

The  funding  level  within  IGR(I) 
represented  by  variable  1 

Input  as  (ILEV(I),  1  =  1,  NVAR) 

(d  +  1)  -  e 

B(L) 

10F8.0 

The  budget  upper  bound  for  period  1 

Input  as  (B(L),  1  =  1,  NPER) 

(e  +  1)  -  f 

A(l) 

10F8.0 

The  contribution  of  variable  1  to 
the  achievement  of  an  objective 

For  each  objective,  input  as 
(A(l),  1-  1,  NVAR) 

*(f  +  1)  -  g 

RHS(J) 

10F8.0 

The  desired  achievement  value 
of  each  goal  or  objective 

Input  as  (RHS(J),  J  =  1,  NG) 

*RHS(J)  is  input  for  RAM/GP  only. 


"FILEOUT"  provides  the  initial  solution  obtained  by 
RAM/VM  under  Phase  1  and  the  final  solution  obtained  under 
Phase  2.  The  results  shown  are  the  variables  contained  in 
the  solution  and  the  corresponding  alternative  group  number 
(mutually  exclusive  group)  and  funding  alternative  number 
(alternative  within  the  associated  group) ,  the  achievement 
vector  for  each  priority  level,  and  the  slack  (or  unused 
resources)  remaining  in  each  period. 

4 .  Sample  Problem 

Table  2  is  a  sample  data  file  for  RAM/VM,  which  is  set 
up  in  the  format  identified  in  Table  1.  Line  (1)  sets  the 
parameters  for  the  problem.  There  are  nine  0-1  variables 
(total  number  of  alternative  groups)  (NVAR=9) ,  two  objectives 
(NG=2) ,  one  priority  level  (NP=1) ,  three  time  periods  (NPER=3) 
and  three  alternative  groups  (NGR=3) .  The  flag,  IGS,  is  set 
to  zero  (IGS=0) ,  indicating  that  for  this  problem  no  alter¬ 
native  groups  need  be  represented  in  the  solution. 


TABLE  2 

SAMPLE  DATA  FILE  FOR  RAM/VM  (IGS  =  0) 


(1) 

9 

2  1 

3 

) 

(2) 

1 

1  2 

1 

(3) 

32 . 003 

2.000 

.>  0.0  00 

10.000 

93.0  00 

0.000 

38.000 

89.000 

7 1  .  003 

(4) 

96.000 

25.000 

33.000 

35.003 

72 . 0  00 

4  9.000 

94 .000 

92 . 000 

96. 000 

(5) 

7.000 

92.000 

3 1 . 003 

84  .000 

0.000 

90.000 

26.000 

1  1  . 000 

47.00) 

(6) 

I 

1  2 

2  2 

2 

3  3 

3 

(7) 

1 

2  1 

2  J 

4 

1  2 

3 

(8)  2  00.000 

1 90 .000 

2  30.  300 

(9) 

69.000 

13.000 

32. 0  00 

2.000 

30.0  30 

10.000 

98.000 

0 .000 

38.000 

(10 

89.0 00 

71  .003 

96. 00 J 

25.000 

33.000 

35.000 

72.000 

48 .0^0 

94 . 003 
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Line  (2)  shows  that  each  objective  is  at  the  first 
priority  level  (PR(J)=1),  J=l,2);  however,  the  second  objec¬ 
tive  is  shown  to  be  twice  as  important  as  the  first.  There¬ 
fore,  the  weighting  factors  are  1  for  the  first  objective 
(W ( 1 ) =1 }  and  2  for  the  second  objective  (W(2)=2). 

Lines  (3)  through  (5)  identify  the  quantity  of  resources 
required  by  each  alternative  during  each  time  period. 

Lines  (6)  and  (7)  identify  which  variables  are  associated 
with  each  alternative  group.  In  this  example,  there  are 
three  such  groups,  the  first  group  having  two  alternatives, 
the  second  group  having  four  alternatives,  and  the  third 
group  having  three  alternatives. 

Line  (8)  identifies  the  total  resources  available  during 
each  of  the  three  time  periods. 

Lines  (9)  and  (10)  identify  the  contribution  of  each 
alternative  to  the  achievement  of  the  two  objectives. 

Mathematically,  the  sample  problem  is  set  up  as  follows: 

Maximize 

Z=  1  (69X  +13X  +32X  +2X  +30X+10X  +98X  +0X  +38X  ) 

1  2  3  *•  56  7B  9 

+  2  ( 89X  +71X  +96X  +25X  +33X  +35X  +72X  +48X  +94X  ) 

1  2  3  4  5  6  7  8  9 

(where  Z  is  the  objective  function,  and  the  coefficients  re¬ 
present  the  contribution  of  each  variable  (alternative)  to 
the  achievement  of  each  objective.) 

Subject  to  the  following  resource  constraints: 

32X  +  2X  +  30X  +  10X  +  98X  +  OX  +  38X  +  89X  +  71X  £  200.0 

1  2  3  4  5  6  7  8  9 

96X  +  25X  +  33X  +  35X  +  72X  +  48X  +  94X  +  92X  +  96X  £  190.0 

1  2  3  4  5  6  7  8  9 

7X  +  92X  +  31X  +  84X  +  OX  +  90X  +  26X  +  11X  +  47X  £  200.0 

1  2  3  4  5  6  7  6  9 
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(where  each  equation  represents  one  time  period,  the  coef¬ 
ficients  identify  the  resources  required  by  each  variable 
(alternative) ,  and  the  righthand  side  provides  the  maximum 
quantity  of  the  resources  available  in  each  time  period.) 

The  constraint: 

X  =  {0,1}  i=l , 9 

requires  that  an  alternative  either  be  selected  or  rejected. 
The  constraints : 


X  + 

1 

X 

2 

< 

1 

(Alternative 

Group 

1) 

X  + 

3 

X  +  X  +  X 

4  5  6 

< 

1 

(Alternative 

Group 

2) 

X  + 

7 

X  +  X 

8  9 

< 

1 

(Alternative 

Group 

3) 

require  no  more  than  one  alternative  to  be  selected  from 
each  alternative  group.  It  is  possible  that  no  alterna¬ 
tives  will  be  selected  from  a  given  group. 

The  solution  to  this  problem  is  shown  in  Table  3.  Note 
the  improvement  in  the  achievement  vector  in  Phase  2  over 
that  in  Phase  1.  RAM/VM  found  an  initial  feasible  solution 
and  then,  through  a  two-for-one  exchange,  improved  the  value 
of  the  objective  function.  The  exchange  replaced  variable 
index  1  with  variable  indices  2  and  7.  The  value  of  the 
achievement  vector  in  the  final  solution  is  621.0.  This  is 
the  value  of  Z  with  X  ,  X  ,  and  X  (the  alternatives 

2  3  7 

associated  with  the  variable  indices  2,  3,  and  7)  set  equal 
to  1  and  all  other  variables  set  to  0;  this  value  represents 
the  optimal  (or  near  optimal)  achievement  with  the  set  of 
constraints.  These  variable  indices  (2,  3,  and  7)  represent 
Alternative  Group  1  (Alternative  2),  Alternative  Group  2 
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(Alternative  1)  and  Alternative  Group  3  (Alternative  1) . 

With  problems  of  more  than  one  priority  level,  the  achieve¬ 
ment  vector  will  be  provided  for  each  associated  priority 
level.  The  output  also  identifies  the  slack,  or  quantity  of 
unused  resources,  remaining  in  each  time  period. 

If,  as  an  additional  constraint,  one  of  the  alternatives 
in  the  third  alternative  group  had  to  be  selected,  IGS  would 
be  set  equal  to  1,  and  an  additional  objective  would  be  added. 
This  objective  would  be  at  the  Priority  1  level  and  would 
be: 

Maximize:  IX  +  IX  +  IX  . 

7  8  9 


The  other  objectives  would  then  be  treated  as  Priority  2 
objectives,  and  the  objective  function  Z  would  be: 

Maximize 


Table  4  shows  how  the  data  file  would  be  set  up  for  such  a 
problem.  Table  4  represents  the  same  problems  as  those  in 
Table  2,  except  it  includes  the  requirement  to  select  one  of 
the  alternatives  from  the  third  alternative  group. 

5 .  Limitations  Due  to  Size  of  Problem 

The  array  dimensions  restrict  the  problem  size  to  200 
goals,  3  priority  levels,  10  budget  periods,  475  alternatives, 
and  150  alternative  groups.  The  problem  size  can  be  in¬ 
creased  through  appropriate  redimensioning  of  the  arrays, 
subject  only  to  time  and  system  limitations. 
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TABLE  4 


SAMPLE 

DATA  FILE 

FOR  RAM/VM  (IGS 

=  1) 

y 

2  2 

3  3 

1 

l 

1  1 

2  2 

2 

32 

.000 

2.000 

j0.  )0 ) 

10.000 

98.000 

0.000 

38 . 000 

89 . 000 

7 1 . 000 

96 

.000 

26.000 

j3.  1  )) 

35.000 

72.000 

48.0)0 

94 .000 

92 .000 

94. 0  V) 

7 

.  000 

92.000 

3  1.)  >0 

34 . 0  00 

0.000 

y 0.0 00 

26.000 

1  1  .000 

47. 0^4 

1 

1  2 

2  2 

~> 

3  3 

3 

1 

2  1 

2  3 

4 

1  2 

3 

200 

.000 

1 90.000 

2  )0.  000 

) 

.000 

0 .000 

0.  )  )0 

0.000 

0.040 

0.000 

1  .0  00 

1  .000 

1  .040 

69 

.  000 

13.000 

32.  )0) 

2.000 

30.000 

1 0.^00 

98.000 

)  .000 

38.040 

dy 

.  000 

7!  .000 

yd.OOJ 

25.000 

33.  000 

35.000 

72 . 000 

43 . 000 

94 . 040 

6 .  Computational  Experience 

We  ran  a  number  of  randomly  generated  problems  on  RAM/VM 
during  a  test  program.  All  the  problems  generated  had  four 
goals,  one  priority  level,  and  four  budget  periods.  Table  5 
provides  a  summary  of  some  of  the  test  program  results.* 

B .  Guide  to  RAM/GP 

RAM/GP  is  a  computer  code  similar  to  RAM/VM  in  that  it 
also  solves  the  multidimensional,  multiple-objective  pack¬ 
ing  problem  and  uses  the  same  ranking  technique  and  ex¬ 
change  heuristic.  RAM/GP,  however,  embodies  more  aspects 
of  the  goal  programming  methodology  for  solving  the  multiple 
objective  problem.  RAM/VM  maximizes  the  achievement  value 
of  all  objectives  for  each  priority  level;  whereas  RAM/GP 
minimizes  the  deviation  from  set  objectives  or  goals  for 
each  priority  level. 


*See  Volume  4  for  additional  test  data. 
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TABLE  5 

SUMMARY  OF  TEST  PROGRAM  RESULTS 


Number  of 
Variables 

Mean  Percentage  of 
Optimum* 

Mean  CPU  Time 
(CPU  secs) 

21 

97.3 

1.44 

40 

97.7 

2.21 

60 

3.75 

75 

6.71 

99 

_t 

9.10 

*We  based  percentage  of  optimum  on  RAM/VM  solutions  that  were 
within  a  percentage  of  an  upper  bound  on  the  optimal  solution. 

The  RAM/VM  solution  may,  therefore,  be  closer  to  the  true  optimal 

^Limitations  of  the  test  program  restricted  the  determination  of  the 
upper  bound  on  the  optimal  solution  for  problems  with  more  than 
50  variables. 


Data  input  for  RAM/GP  differs  from  that  for  RAM/VM  only 
in  that  the  desired  achievement  value  for  each  objective 
is  included  in  the  data  input.  This  value  is  shown  in 
Table  1  as  RHS(J),  the  last  line  of  data  to  be  input.  If 
the  objectives  (RHS(J))  are  set  high  enough  (so  that  they 
cannot  be  attained) ,  RAM/GP  will  arrive  at  the  same  solution 
as  that  of  RAM/VM.  RAM/GP  does  not  give  any  credit  for 
surpassing  goals;  therefore,  the  value  of  the  achievement 
vector  as  provided  by  the  output  will  never  exceed  the  sum 
of  all  goals, 

NG 

(E  RHS  (J)), 

J=1 

even  though  the  set  goal  for  some  (or  all)  objectives  may 
be  exceeded. 
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The  information  provided  by  the  output  from  RAM/GP  is 
the  same  as  that  provided  by  RAM/VM  output.  The  solutions 
obtained  from  RAM/GP  during  the  test  program  compared 
favorably  with  those  of  RAM/VM  and  should  be  within  2  to  3 
percent  of  optimum  for  problems  with  less  than  50  variables. 
RAM/GP  does  require  more  CPU  time  to  arrive  at  the  solution 
than  does  RAM/VM. 
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IV.  COMPUTER  CODES 


This  chapter  contains  the  computer  program  listings  for 
RAM/GP  and  RAM/VM. 

A.  RAM/GP 


PROGRAM  RAM/GP  »«********«**«»**»*»»*•»*.»»*» 

C 

C  ... .SUBROUT  I NE  FUNCTIONS 
C 

C  1  FEAS- -CHECKS  AN  EXCHANGE  OPERATION  FOR  BUDGET  FEASIBILITY. 

C 

C  2  COMPARE- -CHECKS  AN  OPERATION  FOR  PROFITABILITY. 

C 

C  3.  RERANK- -REORDERS  THE  PROJECTS  IN  THE  SETS  JS  AND  NS  AFTER 

C  EACH  EXCHANGE.  ( JS  IS  RANKED  IN  ASCENDING  ORDER  OF  PROFIT, 

C  NS  IN  DESCENDING  ORDER) 

C 

C  4.  F I TBACK - -USES  UP  BUDGET  SLACK  BY  ADDING  ANY  FEASIBLE  PROJECTS 

C  (REGARDLESS  OF  RELATIVE  PROFIT)  TO  JS. 

C 

CXXXXXXXX^XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

C 

C  ....INPUT  variables 

c 

C  1.  NVAR--THE  NUMBER  OF  0-1  VARIABLES. 

C  2.  NG- -THE  NUMBER  OF  OBJECTIVES. 

C  3.  NP- -THE  NUMBER  OF  PRIORITY  LEVELS. 

C  4.  NPEP -  - THE  NUMBER  OF  BUDGET  PERIODS. 

C  5  NGR -  -  THE  NUMBER  OF  MUTUALLY  EXCLUSIVE  GROUPS  (ALTERNATIVE  GROUPS) 

C  6.  W( J ) - -THE  WEIGHTING  FACTOR  ASSOCIATED  WITH  OBJECTIVE  J. 

C  7.  PR{ J I  - -THE  PRIORITY  LEVEL  WHICH  INCLUDES  OBJECTIVE  J. 

C  8.  I GR (I  I  -  -  THE  ALTERNATIVE  GROUP  WHICH  CONTAINS  VARIABLE  I. 

C  9.  A ( I ) - -  THE  CONTRIBUTION  OF  VARIABLE  I  TO  THE  ACHIEVEMENT  OF 

C  AN  OBJECTIVE. 

C  10.  C ( I , L I  -  -  THE  COST  OF  VARIABLE  I  IN  BUDGET  PERIOD  L. 

C  11.  BCD --THE  BUDGET  UPPER  BOUND  FOR  PERIOD  L. 

C  12.  I  LEVI  I ) - -THE  FUNDING  LEVEL  WITHIN  IGR(I)  RFPRESFNTED  BY  VARIABLE  1 

C  13.  1 GS --IF  SET  TO  1,  INDICATES  THE  PRESENCE  OF  ALTERNATIVE  GROUP; 

C  WHICH  MUST  BE  FUNDED  AT  SOME  NON-ZERO  LEVEL, 

C 

c*. .***».*» .*.*■*»» i  i 


c***» INTERNAL  VARIABLES 
C 

C  1.  R( I ) - -THE  PROPORTION  OF  AVAILABLE  FUNDS  REQUIRED  BY 

C  VARIABLE  I,  AVERAGED  OVER  ALL  BUDGET  PERIODS. 

C  2.  AHC 1  ,  K  )  - -FOR  EACH  VARIABLE  l.THIS  IS  AN  NP - D I  MENS  1 ONAL  VECTOR, 

C  WHOSE  KTH  COMPONENT  IS  A  WEIGHTED  SUM  OF  CONTRIBUTIONS  OF  VARIABLE  I 

C  TO  THE  OBJECTIVES  AT  PRIORITY  LEVEL  K. 

C  3.  JNIF--A  FLAG  WHICH  COMMUNICATES  THE  CURRENT  STAGE  TO  THE 

C  SUBROUTINE  'COMPARE1. 

C  4.  INC(I) --HAS  A  VALUE  OF  1  IF  VARIABLE  I  IS  IN  THE  SOLUTION; 

C  O  OTHERWISE. 

C  5.  1 GR (Ml- -HAS  A  VALUE  OF  1  IF  THE  GROUP  M  IS  REPRESENTED  IN 

C  THE  SOLUT 1  ON ; 0  OTHERWISE 

C  G.  JSCM)--TAKES  ON  THE  INDEX  NUMBER  OF  THE  MTH  VARIABLE 

C  IN  THE  SOLUTION 

C  7.  JL- -THE  NUMBER  OF  VARIABLES  CURRENTLY  IN  THE  SOLUTION  SET;JS(M>. 

C  8.  NSCM) --TAKES  ON  THE  INDEX  NUMBER  OF  THE  MTH  VARIABLE  NOT  IN  THE 

C  SOLUTION. 

C  9.  LL- -THE  NUMBER  OF  VARIABLES  CURRENTLY  OUT  OF  THE  SOLUTION 

C  10  SLACK ( L ) - - A  VECTOR  WHICH  INDICATES  UNSPENT  FUNDS  IN 

C  EACH  BUDGET  PERIOD  FOR  THE  CURRENT  SO.UTION. 

C  11.  NUMF --IS  A  FLAG  WHICH  INDICATES  THE  TYPE  OF  EXCHANGE 

C  TO  PERFORM. 

C  12.  PROF ( K ) - -  I S  A  NP-D I  MENS  I ONAL  VECTOR  WHOSE  KTH  COMPONENT 

C  IS  THE  PROFIT  GAINED  IN  THE  KTH  PRIORITY  LEVEL  SO  FAR  IN 

C  THE  CURRENT  EXCHANGE  CYCLE. 

C  13.  PROFN (  K  )  -  -  I  S  A  NP -D I  MENS I ONAL  VECTOR  WHOSE  KTH  COMPONENT  IS  THE 

C  PROFIT  IN  THE  KTH  PRIORITY  LEVEL  FOR  THE  EXCHANGE 

C  UNDER  CONSIDERATION. 

C  14.  I  FLAG- -TAKES  ON  A  VALUE  OF  1  IF  AN  EXCHANGE  IS  PROFITABLE; 

C  O  OTHERWISE. 

C  15.  JFLAG- -TAKES  ON  A  VALUE  OF  1  IF  AN  EXCHANGE  IS  FEASIBLE;  0  OTHERWISE 

C  16.  CANDI I ) --TAKES  ON  THE  INDEX  NUMBER  OF  THE  I TH  VARIABLE 

C  IN  THE  FITBACK  SET. 

C 

C ***:**»***•*******************»****************«*«»**«**»***********»** 

C«**«CURRENT  DIMENSION  STATUS 
C 

C  1 .  NUMBER  OF  GOALS:  200 

C 

C  2.  NUMBER  OF  PRIORITY  LEVELS:  3 

C 

C  3.  NUMBER  OF  BUDGET  PERIODS  :  10 

C 

C  4.  NUMBER  OF  0-1  VAR  I ABLES ( ALTERNAT I VES )  :  475 

C 

C  5.  NUMBER  OF  ALTERNATIVE  GROUPS:  150 


RAM/GP  WAS  DEVELOPED  AND  WRITTEN  AT 

ANALYTIC  SERVICES,  INC 
l  TACT  I  CAL  DIVISION) 

400  ARMY -NAVY  DRIVE 
ARLINGTON,  VIRGINIA  22202 

(703)  979-0700 
AV  225-5  61.0 
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DIMENSION  R(475> 

INTEGER  PR (475 ) , W (475 ) 

INTEGER  OV,HV,OV1 , 0V2 

COMMON  /COMM 1 /  SL (1 0 ), C < 200, 1 0 ), NPER, JFLAG , SLACK ( 1 0 ) 
COMMON  /C0MM2/  JS(50),JL 

COMMON  /C0MM3/  AH ( 200 , 3 ) , PROF ( 3 ) ,  I  FLAG , NP , PROFN ( 3 ) 

COMMON  /C0MM4 /  I GN ( 50 ) , I NC ( 200 > , CAND ( 50 > , NGR , NVAR 
S,LK, ILEVC200),ACH(3) 

COMMON  /COMM 5/  NUMF , OV , JV , KV , LV , MV , HV ,  I  OUT 1 ,  I 0UT2 
s  ,  l OUT 3 ,  ! N 1  ,  I N2 ,  I N3 , NL , NM , NH ,  I  I  , JJ,KK 
S,  IA, IB,  1C,  IAA,  IBB,  ICC 
COMMON  /COMMS/  NS ( 200 ) , LL, I GR ( 200 ) 

COMMON  /C0MM7/  1NIF 
COMMON  /C0MM8/  B(10) 

COMMON  /C0MM9/  A ( 200 , 50 ) , RHS ( 50 ) , PER ( 50 ) , FXT ( 50 ) , JW t 200 ) , 
6NG, I PR ( 200 ) 

READC 10,501)  NVAR, NG,NP,NPER, NGR 
READ (10,502)  ( JW ( J ) ,  I  PR ( J ) , J  = 1 , NG ) 

DO  737  L*1 , NPER 

737  READ (10, 503 )  ( C ( I , L ) , 1 = 1 , NV AR ) 

READ (10, 502 )  ( I GR ( l ) , I = 1 , NVAR ) 

READ (10, 502 )  ( I  LEV ( I  ) ,  I  =  1 , NVAR ) 

READ (10, 503 )  ( B ( L ) , L= 1 , NPER ) 

DO  714  J*1  , NG 

714  READ (10,503)  ( A ( I , J ) , I = 1 , NVAR ) 

READ (10, 503 )  ( RHS ( J ) , J  =  1 , NG  ) 

I  SI Z= 1 

501  FORMAT ( 1615) 

502  FORMAT ( 1615) 

503  FORMAT < 1 0F8 . 3) 

996  FORMAT ( '  ',2515) 

C  1 .  CALCULATE  R( 1 ) 

NVAR = NVAR +1 
NGR=NGR+1 
DO  904  K= 1 , NG 
A ( NVAR , K 1  *0. 

904  CONTINUE 

DO  905  K=1  ,  NP 
AH ( NVAR , K ) " 0 . 

905  CONTINUE 

I GR ( NVAR 1 *NGR 
I  LEV ( NVAR )  =  1 
DO  906  L* 1 , NPER 
C ( NVAR , L 1 =  999999 . 

906  CONTINUE 

DO  1  I  «  1 , NVAR 
R ( I  1*0.0 

DO  2  L  «  1 , NPER 
R ( 1 l=R( 1  I ♦ ( C <  I ,L)/B(L)  ) 

2  CONTINUE 

R ( I  I  *  R( I ) /NPER 
1  CONTINUE 

C  2.  CALCULATE  AH(I,K> 

DO  4  K=1 ,NP 

DO  4  I  «  1 , NVAR 

AH ( I , K  )  *  0.0 

4  CONT 1 NUE 

DO  3  J  ■  1  ,  NG 

K« IPR<  J ) 

DO  5  1  «  1 , NVAR 

AA  *  (A(I,J)«JW(J))/R(I) 

AH( I , K )  «  AHt I , K )  ♦  AA 

5  CONT 1 NUE 

3  CONTINUE 

C  DETERMINE  INITIAL  SOLUTION 
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C  1.  SET  MAX ( A/R ) !  FOR  EACH  GROUP. 

INIF  =  1 
LL  =  0 

DO  6  M  *  1 , NGR 
MAX=0 

DO  7  I  ■  1  , NVAR 
I F ( IGR( I )  , NE .  M)  GO  TO  7 
I NC ( I >=0 

IV=I 

I F  C  MAX . EG . 0 )  GO  TO  101 
CALL  COMPARE  (1V,0V,1NIF> 

I F ( INC ( I  1 . EO . 0)  GO  TO  102 

LL=LL+1 

NS ( LL ) =0V 

OV  =  I 

GO  TO  7 

102  LL  =  LL  ♦  1 
NS(LL)  =  I 
GO  TO  7 

101  OV=l 

INCt I )=1 
MAX=  1 

7  CONTINUE 
JSCM1-0V 

6  CONTINUE 

INIF  =  0 

C***»»»*  RANK  (JS'**«****»«»»»»***»* 

DO  8  M  =  2 , NGR 
N  =  M 

103  M0=JS(N-1) 

MN=JS<N) 

CALL  COMPARE  f  MN , MO ,  I N I F ) 

I F ( I  FLAG  . EQ  0)  GO  TO  8 
INTER  =  JSCN-1 ) 

JSCN-1 )=JS(N) 

JS(N)-!NTER 
N  =  N-  1 

IF(N-I)  8,8,103 

8  CONTINUE 
JL=NGR 

C***CHECK  CJS)  FOR  FEASIBILITY  AND  DELETE  BOTTOM  ENTRY  IF  NOT  FEASIBLE 

104  DO  9  L  =  1  , NPER 
CC  =  0  0 

DO  10  M  =  1 , JL 
I =JS(M) 

CC*CC+C( I , L) 

IFCCC.GT.BCL) >  GO  TO  105 
10  CONTINUE 

SLACK (L)=B(L)-CC 

9  CONTINUE 
GO  TO  106 

105  I  I  *  JSC JL) 

INCH  I  )=0 
JL  =  JL  *  1 
LL*LL+ 1 
NSCLLMI  I 
GO  TO  104 

106  DO  11  K  *  1,NP 
DO  1 1  I  »  1  , NVAR 
AH< I ,K)*AH( I ,K)«R< I ) 

1  1  CONT I NUE 

DO  769  I  *  1 , LL 
J ■ NS ( I ) 
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769  CONTINUE 

CALL  RERANK 
DO  797  I *1 , LL 
J  =  NSC  I  ) 

797  CONTINUE 
500  CONTINUE 
KKFL*0 

CALL  F I TBACK ( KKFL ) 

I0FL*1 

CALL  OUTPUT ( I OFL ) 

C*  *  **  *  *  *SECT I  ON  2  FIRST  EXCHANGE********* 

DO  722  1=1 ,LL 
J  =  NS< 1  ) 

722  CONTINUE 
116  CONTINUE 

DO  12  K  =  1  ,  NP 
PROF  C  K ) =0 . 0 
1 2  CONT I NUE 

NV2=NVAR-*2 
I  N I  F  =  3 

DO  13  NL= 1 ,LL 

NH=NL+1 

JJFL=1 

109  IFCNH.GT.LL)  GO  TO  13 
HV  =  NS(NH) 

LV=NS ( NL I 

IFCIGRCHV)  .EO  IGRCLV))  GO  TO  107 
GO  TO  106 

107  NH=NH+1 
GO  TO  109 

1 08  CONT I NUE 

DO  15  L=1 , NPER 
C(NV2,L)=C(HV,L)*C(LV,L) 

15  CONTINUE 

DO  16  I  I  =  1  , JL 
OV  =  JS< 1  I  1 
IS= 1GR<  LV) 

I X= I GR C HV ) 

IFC  1GNM  S)  .  NE  .  0.  AND  1 GRC LV ) . NE . I GR ( OV > >  GO  TO  16 
DO  30  K= 1 , NP 
AH  C  NV2 , K ) =  0 . 

AH(LV,K) =0. 

30  CONTINUE 

DO  14  J  =  1 ,  NG 

R1 = A ( LV , J ) *A ( HV , J ) 

D 1 =  A  ( LV , J  ) 

RNEED  =  EXT  <  J  >  +  A  C OV , J) 

I F C RNEED . LT . 0 .  ) RNEED  =  0 . 

R2  =  AM  I N 1  ( R 1 .RNEED) 

D2  =  AMI N1  C  D 1  , RNEED) 

LY* I  PR ( J I 

AH  C  NV2 , LY ) =  AH  C  NV2 , LY ) ♦ ( R2 *  JW  C  J ) > 

AH ( LV , LY ) = AH ( LV , LY ) +(D2* JW( J) ) 

14  CONTINUE 

IF< IGN( IX)  NE.O.AND  IGR(HV)  . NE .  IGR(OV)  )  GO  TO  110 
NV*NV2 

CALL  COMPARE (NV.OV, INI F) 

IFC I  FLAG . EO  0)  GO  TO  111 
CALL  FEASCOV.NV) 

IFC JFLAG.EQ. 0)  GO  TO  110 
NUMF  =2 
60  TO  112 
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110  IFCJJFL.GT. I >  GO  TO  16 
NV  =  LV 

IFCNV.EQ.LNM. AND.OV.EQ.LNN)  GO  TO  16 
CALL  COMPARE CNV.OV, IN1F) 

LNM=NV 

LNN=OV 

| F ( I  FLAG . EO  0 )  GO  TO  16 
CALL  FEAS ( OV , NV 1 
I F ( JFLAG  .EO  0)  GO  TO  16 
NUMF  =  1 
GO  TO  112 

111  NH=NH+1 
JJFL=2 

GO  TO  109 

112  DO  17  K  =  1,NP 
PROF ( K ) =  PROFN ( K ) 

17  CONTINUE 
1 A  =  I  1 
I  OUT  =  0V 
INI  =  LV 
IAA  =  NL 

I F ( NUMF . NE . 2 )  GO  TO  113 
IN2  =  HV 
IBB  .  NH 
GO  TO  111 

113  IN2  =  0 
16  CONTINUE 

GO  TO  107 
13  CONTINUE 

DO  16  K=1 ,NP 

IF  CPROF(K) .GT. 0. 0)  GO  TO  114 
16  CONTINUE 
KKFL  =  1 

CALL  FI TBACKCKKFL) 

10FL=2 

CALL  OUTPUT! I OFL) 

CALL  RERANK 
GO  TO  118 

114  I NC  C 1  OUT  I =0 
INCUN1  )  =  1 

I NTER3  =  JS ( IA) 

JS( I A ) -NS ( IAA) 

N=  JSC  1  A) 

I Js IGR(N) 

NSC  I AA )  =  I NTER3 
IPsIGRC 1NTER3) 

IGNC IP)=0 
I GNC I J ) = 1 

IFC IN2. EO. 0)  GO  TO  115 

LLL=0 

LL=LL-1 

DO  396  I  *  1 , LL 

J-l*1 

IFCNSC I ) .EO  IN2)  LLL* 1 
IFCLLL.EO.  1 )  NSC  I  )=NSC J) 

396  CONTINUE 

I  NC  C I N2 )  =  1 
JL.JL+1 
JSCJL)=IN2 
LX. | OR ( I N2) 

I GN  C  LX )  =  1 
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mi, 


mm 


115  CALL  RERANK 

DO  28  L=  1  , NPER 
CC  =  0  0 

DO  29  M=1,JL 
I  =  JS  ( M  ) 

CC=CC+C( I  .  L) 

29  CONTINUE 

SLACK ( L ) =B ( L ) -CC 
28  CONTINUE 
GO  TO  116 
118  CONTINUE 
810  I0FL=3 

CALL  OUTPUT ( IOFL) 

CLOSE ( 8 ) 

CLOSE < 101 

STOP 

END 

CaaxaaSUBROUTINESa.aaaaaaaaaaaaaaaaa.aaaaaaaa* 

SUBROUTINE  FEAS ( LOV , NV ) 

COMMON  /COMM  1 /  SL ( 1 0 ), C ( 200 ,  1 0 ), NPER , JFLAG , SLACK ( 1 0 ) 
COMMON  /COMM 7/  1NIF 
DO  1  L~ 1 , NPER 
SL(L)  *  SLACK ( L ) 

SLCL>  =SLCL) +C(LOV, L) -C(NV, L) 

SLF=SL(L) ♦  0005 
IF(SLF)  10,1,1 

I  CONTINUE 
JFLAG- 1 
GO  TO  11 

10  JFLAG=0 

I I  RETURN 
END 

£a  a  *a  a  *  * RE RANK  (JS)  AND  ( NS ) a  a  a  a  a  a  a  a » a  a  *  * » a 
SUBROUTINE  RERANK 
COMMON  /C0MM2/  JS(50),JL 
COMMON  /COMM 7/  INIF 

COMMON  /COMM 3/  AH ( 200 , 3 ) , PROF ( 3 ) ,  I  FLAG , NP , PROFN ( 3 ) 

COMMON  /C0MM4 /  1 GN ( 50 ) , I NC ( 200 ) . CAND ( 50 > , NGR , NVAR 
«.LK,  1  LEV (200) , ACHf 3) 

COMMON  /C0MM6/  NS ( 200 ) , LL , I GR ( 200 ) 

COMMON  /COMM 9/  A ( 200 , 50 ) , RHS ( 50 ) , PER ! 50 ) , EXT ( 50 ) , JW ( 200 ) , 
«NG,  I  PR (200) 

INIF  =  0 
DO  1  J  =  1  , NG 
PER  ( J  >  =0 • 

1  CONTINUE 

DO  2  I  0* 1 , JL 
DO  2  J* 1 .NG 
I *JS< 10) 

PER( J ) *PER ( J ) *A( I , J) 

2  CONT I NUE 

DO  3  J  *  1  .  NG 

EXT  C  J ) * RHS ( J ) -PER  <  J  ) 

3  CONT I NUE 

DO  4  I  *  1 , JL 
DO  4  K  = 1 . NP 
LZ*JS( I ) 

AHCLZ,  K ) *0 

4  CONT I NUE 
QL«0 . 

DO  5  I0«1 , JL 
DO  5  J  a  1 , NG 
I ■ J  S ( 10) 
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RV  =  A(  I  ,  J  )  »£XT (  J  ) 

IFCRV. LT.O. )  RV  =  0. 

APS=A< 1  ,  J  ) 

RSV=AM!N1 ( APS , RV ) 

K -  I  PR ( J ) 

AH( I , K ) =  AH( I , K ) +RSV* JWC J ) 
CONTINUE 

IFCJL.LT. 2)  GO  TO  71 
DO  70  M=2,JL 
N  =  M 

700  M0=JS(N-1) 

MN=JS(N) 

CALL  COMPARE ( MN , MO , I N I F ) 
IF( I  FLAG . EO .  1  )  GO  TO  70 
INTER=JSCN-1 ) 

JSCN-1  ) *  JS ( N ) 

JS(N)= INTER 
N  =  N-1 


IFCN-1)  70,70,700 

70  CONTINUE 

71  CONTINUE 

C*x*»*»v******«*xxx*xftx*v  (  N'S 

DO  57  M  =  2, LL 
N  =  M 


604  M0=NS(N-1) 

MN=NS(N) 

CALL  COMPARE ( MN , MO , I N I F ) 

I F (  I  FLAG . EO  0 )  GO  TO  57 
I NTER*  NS ( N -  1  ) 

NSC  N" 1  )  *  NS  C  N ) 

NSCN)  =  INTER 
N  =  N-1 

IFCN-1 )  57,57,604 
57  CONT I NUE 

DO  100  I = 1 , JL 
I  I =  JS<  I  ) 

100  CONTINUE 
RETURN 
END 

C*  *********  *  EXECUTE  FI  TBACK********  ********* 

SUBROUTINE  FI TBACK  CKKFL) 

COMMON  /COMM  1 /  SL  C 1 0 ) , C  C  200 ,10), NPER, JFLAG , SLACK (10) 
COMMON  /C0MM2/  JS(50),JL 

COMMON  /C0MM4 /  I GN ( 50 ) , I NC ( 200 > , CAND ( 50 > , NGR , NVAR 
«,  LK, I  LEV C  200 ) , ACHC  3) 

COMMON  /C0MM6/  NS ( 200 ) , LL , I GR ( 200 ) 

COMMON  /COMM 7/  INIF 
DO  15  L*  1  , NPER 
SL ( L  )  *  SLACK ( L ) 

15  CONTINUE 

DO  11  M= 1 , NGR 
I GNCM ) =0 
11  CONTINUE 

DO  10  1*1, JL 
N*  JSC  I ) 

M=IBR(N) 

I GN  C  M ) *  1 
1 0  CONT I NUE 
LK*0 

DO  12  1*1, LL 
I  I *NS(  I  ) 
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M- I GR( I  1  I 

I F  (  I GN (Ml. NE . 0 )  GO  TO  12 
DO  13  L*  1 . NPER 

IF(C( I  1 ,  L> .GT.SLCL)  )  GO  TO  12 

13  CONTINUE 
LK=LK+1 
CAND ( LK ) *  I  I 

DO  14  L  = 1 , NPER 
SL(L)=SLCL>-C< I  1  ,  L ) 

14  CONTINUE 
12  CONTINUE 

IFCKKFL  .EO.  0  .OR.  LK  EG.  01  GO  TO  17 
DO  18  I  *  1 , LK 
JJ  *  CAND ( I ) 

INCtJJI  *1 
JL  =  JL  ♦  1 
LL  «  LL-1 
JSC  JL 1  *  JJ 
JK  =  IGRCJJ) 

IGNCJK)  *1 
18  CONTINUE 

17  CONTINUE 
RETURN 
END 

SUBROUTINE  COMPARE (  I N ,  I  0 ,  I N 1 F ) 

COMMON  /COMM 3/  AH f 200, 3 ) , PROF ( 3 1 ,  1  FLAG , NP, PROFN ( 3 ) 
COMMON  /C0MM4 /  I GN ( 50 ) , I NC ( 200 ) , CANDC 50 ) , NGR , NVAR 
«,LK„ I  LEV  C  200 ) , ACH ( 3 1 
COMMON  /C0MM2/  JS<50),JL 
I F ( IN1F  .NE.  1 1  GO  TO  1 1 
DO  1  K  «  1,NP 

IFCAHUN.K)  -  AHCIO.K))  2,1,3 

1  CONTINUE 

2  GO  TO  10 

3  INC(IN)  «  1 

I NC  CIO)  *  0 

GO  TO  10 

11  IFC INIF  .NE  0)  GO  TO  12 
DO  4  K  *  1 , NP 

IFC AH (IN, K)  -  AH CIO, K))  3,4,6 

4  CONTINUE 

5  I  FLAG  =  0 
GO  TO  10 

6  I  FLAG  =  1 
GO  TO  10 

12  IFC INIF  .NE.  3)  GO  TO  10 
DO  7  K  ■=  1  ,  NP 

PROFN ( K )  ■=  AH ( I N , K ) -AH ( I  0 , K ) 

7  CONTINUE 

DO  8  K  *  1  ,  NP 

IFCPROFNCK) -PROFCK))  18,8,20 

8  CONTINUE 

18  I  FLAG  =  0 
GO  TO  10 

20  I  FLAG  =  1 

10  RETURN 

ENO 

SUBROUTINE  OUTPUT ( I OFL) 

COMMON  /COMM 4 /  I GN ( 30 ) , I NC C 200 ) , CAND C 30 > , NGR , NVAR 
C . LK , I  LEV  1 200 ) , ACH ( 3 ) 
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COMMON  /COMM2/  JS(50),JL 

COMMON  /COMM 3/  AH ( 200 , 3 > , PROF < 3 ) ,  1  FLAG , NP , PROFN < 3 > 

COMMON  /C0MM6/  NS ( 200 ) , LL , I GR < 200 ) 

COMMON  /C0MM1 /  SL ( 1 0 ), C ( 200 , 1 0 ), NPER , JFLAG , SLACK ( 1 0 ) 
COMMON  /COMM 8/  B(10) 

COMMON  /C0MM9/  A ( 200 . 50 ) , RHS ( 50 ) . PER ( 50 ) , EXT ( 50 ) . JW ( 200 ) . 
6NG,  I  PR (200) 

IF( IOFL.GT. n  GO  TO  973 

OPEN (8, FORM= " FORMATTED" , ACCESS = "SEQUENT  I  AL  "  , MODE  = "OUT" , 
6CARR I  AGE  = . TRUE .  , F 1 LE= " F 1 LEOUT "  ) 

973  WR 1 TE ( 8 , 600 ) 

DO  398  K= I , NP 
398  ACH  C  K ) =  0 . 0 

I F ( IOFl.NE. 1 )  GO  TO  25 
WR I TE l 8 , 60 1 )  I OFL 
WRITE (8, 602) 

WR I TE ( 8 , 603 ) 

DO  400  I  *  1 , JL 
I  I =  JS( I  ) 

WRITE (8, 604)  JS ( 1) ,  I GR (  I  I  )  ,  ILEV(  I  I  ) 

400  CONTINUE 

DO  418  J  = 1  , NG 
EE=C-1 . )*EXT< J) 

E  J  =  0 . 

E 1 =  AMAX 1 CEE.EJ) 

P2=PER< J ) -El 
L=IPR( J) 

418  ACH  C  L ) =  ACH ( L ) +  P2*  JW ( J ) 

IF(LK.EQ.O)  GO  TO  777 
WR I TE ( 8 , 605 ) 

WRITE(8, 603) 

DO  401  1-1, LK 

I  I *CAND (  I  ) 

WR I TE ( 8 , 604 )  I  I  ,  I GR (  I  I  ) ,  I  LEV C I  I  ) 

DO  401  K=  1  , NP 
ACH(K)=ACH(K)+AH(  I  I  ,K) 

401  CONTINUE 
GO  TO  777 

25  I F( IOFL.NE. 2)  GO  TO  50 
WR I TE ( 8 , 60 1 )  I OFL 
WRI TE( 8, 602) 

WRITE (8, 603) 

DO  403  1=1 , JL 
I  I = JSC  I  ) 

WR I TE ( 8 , 604 )  JS ( I  ) ,  I GR  < I  I  ) .  I  LEV ( I  I  ) 

403  CONTINUE 

DO  419  J= 1 , NG 
EE= ( -  1  .  )  *EXT ( J ) 

EJ  =  0 

El =AMAX1 (EE, EJ) 

P2=PER( J)-E1 
L=IPR( J) 

419  ACH ( L ) = ACH ( L ) +P2*  JW ( J ) 

GO  TO  777 

50  DO  405  K«1 ,NP 

I F ( PROF ( K ) . GT . 0 . )  GO  TO  794 
405  CONTINUE 
GO  TO  795 
794  CONT 1 NUE 

WRI TE ( 8, 601 )  I OFL 
WRITE! 6, 602) 

WRI TE( 8, 603) 

DO  406  I • 1 , JL 
I  I >JSC I  ) 

IF(JSd).EQ  O)  GO  TO  406 

WRI TEC  8, 604 )  JSC  I ) , IGR( I  I ) ,  ILEV< I  I  ) 
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DO  407  K*1 , NP 
ACHCK)=ACH!K)+AH! i ! ,K) 

407  CONTINUE 
406  CONTINUE 
777  WRt TE!  8 , 606 ) 

DO  402  K= 1 , NP 
402  WR 1 TE ( 8 , 607 )  K , ACHCK ) 

795  CONTINUE 

I F ( I0FL.NE.3)  GO  TO  909 
DO  411  L= 1 , NPER 
CC=0. 0 

DO  417  M=1 , JL 
I s  JS  CM) 

CC*CC+C( I , L ) 

417  CONTINUE 

SLACK ! L  )  SB( L  ) -CC 

WR 1 TE ( 8 , 609 )  L , SLACK ( L ) 

411  CONTINUE 
909  CONTINUE 
RETURN 

600  FORMAT! ■ 1 35X , 'MULTIPLE  OBJECTIVE  RESOURCE  ALLOCATION 
6  SOLUTION  SYSTEM  OUTPUT '  ) 

601  FORMAT! ' 1 ', 55X, 'OUTPUT  FROM  PHASE  ‘,11) 

602  FORMAT !  ' 0 ' , 45X ,  ' THE  FOLLOWING  VARIABLES  ARE  IN  THE  SOLUTION  ) 

603  FORMAT! 'O' , 17X, 'VARIABLE  I NDEX ' , 1 7X , ' ALTERNAT I VE  GROUP  NUMBER  ,17X, 
«• FUNDING  ALTERNATIVE  NUMBER ' ) 

604  FORMAT (  '  ' , 23X,  I  3, 30X ,13, 38X ,12) 

605  FORMAT! 'O' ,59X, 'FITBACK  VARIABLES') 

606  FORMAT (  '  0  '  ,  1 5X ,  ' ACH I EVEMENT  VECTOR ' > 

607  FORMAT!'  '  , 20X ,  ' PR  I  OR  1 TY  '  I  1 , 5X , F 1 0 . 4 ) 

609  FORMAT!  'O'  ,40X,  'SLACK  REMAINING  I N  PER  I OD  ' ,  I  2 ,  '  :  ' , 5X , F 1 0 . 6 ) 

END 
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B.  RAM/VM 


Iinitiimmitiiiiiiii  PROGRAM  RAM/VM  x  *  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  *  x  x  »  x 
xxxxSUBROUTI NE  FUNCTIONS 

1.  FEAS- -CHECKS  AN  EXCHANGE  OPERATION  FOR  BUDGET  FEASIBILITY. 

2  COMPARE- -CHECKS  AN  OPERATION  FOR  PROFITABILITY. 

3.  RERANK  - -REORDERS  THE  PROJECTS  IN  THE  SETS  JS  AND  NS  AFTER 
EACH  EXCHANGE.  ( JS  IS  RANKED  IN  ASCENDING  ORDER  OF  PROFIT, 

NS  IN  DESCENDING  ORDER) 

4  F 1 TBACK -  - USES  UP  BUDGET  SLACK  BY  ADDING  ANY  FEASIBLE  PROJECTS 
(REGARDLESS  OF  RELATIVE  PROFIT)  TO  JS. 


iu«l  NPUT  VARIABLES 

1.  NVAR -  - THE  NUMBER  OF  D-l  VARIABLES. 

2.  NG -  - THE  NUMBER  OF  OBJECTIVES. 

3.  NP -  *  THE  NUMBER  OF  PRIORITY  LEVELS. 

4.  NPER -  -  THE  NUMBER  OF  BUDGET  PERIODS. 

5.  NGR--THE  NUMBER  OF  MUTUALLY  EXCLUSIVE  GROUPS  (ALTERNATIVE  GROUPS). 

6.  W ( J ) -  - THE  WEIGHTING  FACTOR  ASSOCIATED  WITH  OBJECTIVE  J. 

7.  PR ( J ) -  -  THE  PRIORITY  LEVEL  WHICH  INCLUDES  OBJECTIVE  J. 

8.  I GR (  I  ) -  -  THE  ALTERNATIVE  GROUP  WHICH  CONTAINS  VARIABLE  I. 

9.  A (  I  ) -  -  THE  CONTRIBUTION  OF  VARIABLE  I  TO  THE  ACHIEVEMENT  OF 
AN  OBJECTIVE. 

10.  C ( I , L ) -  -  THE  COST  OF  VARIABLE  I  IN  BUDGET  PERIOD  L. 

11.  B ( L ) -  - THE  BUDGET  UPPER  BOUND  FOR  PERIOD  L. 

12.  ILEV(1)--THE  FUNDING  LEVEL  WITHIN  IGRII)  REPRESENTED  BY  VARIABLE  1 

13.  1GS--1F  SET  TO  1,  INDICATES  THE  PRESENCE  OF  ALTERNATIVE  GROUPS 

WHICH  MUST  BE  FUNDED  AT  SOME  NON-ZERO  LEVEL. 


x  x  *x  ] NTERNAL  variables 

1.  R ( I ) - - THE  PROPORTION  OF  AVAILABLE  FUNDS  REQUIRED  BY 
VARIABLE  1. AVERAGED  OVER  ALL  BUDGET  PERIODS. 

2.  AH  t I , K ) - -FOR  EACH  VARIABLE  I,  THIS  IS  AN  NP -DI MENS  I ONAL  VECTOR, 

WHOSE  KTH  COMPONENT  IS  A  WEIGHTED  SUM  OF  CONTRIBUTIONS  OF  VARIABLE  I 
TO  THE  OBJECTIVES  AT  PRIORITY  LEVEL  K. 

3.  1NIF--A  FLAG  WHICH  COMMUNICATES  THE  CURRENT  STAGE  TO  THE 
SUBROUT  I NE  ' COMPARE '  . 

4  I NC (  1  ) -  - HAS  A  VALUE  OF  1  IF  VARIABLE  I  IS  IN  THE  SOLUTION, 

0  OTHERWISE 

5.  I GR ( M ) -  - HAS  A  VALUE  OF  1  IF  THE  GROUP  M  IS  REPRESENTED  IN 
THE  SOLUTION, 0  OTHERWISE 

6.  JS(M) --TAKES  ON  THE  INDEX  NUMBER  OF  THE  MTH  VARIABLE 
IN  THE  SOLUTION 

7.  JL -  - THE  NUMBER  OF  VARIABLES  CURRENTLY  IN  THE  SOLUTION  SET;JS(M). 

8.  NS(M>- -TAKES  ON  THE  INDEX  NUMBER  OF  THE  MTH  VARIABLE  NOT  IN  THE 
SOLUTION 

9.  LL--THE  NUMBER  OF  VARIABLES  CURRENTLY  OUT  OF  THE  SOLUTION 

10.  SLACK ( L ) - - A  VECTOR  WHICH  INDICATES  UNSPENT  FUNDS  IN 
EACH  BUDGET  PERIOD  FOR  THE  CURRENT  SOLUTION. 

11.  NUMF --IS  A  FLAG  WHICH  (NOICATES  THE  TYPE  OF  EXCHANGE 
TO  PERFORM. 
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c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c« 


12.  PROF ( K  )  -  -  1  S  A  NP - D 1  MENS ! ONAL  VECTOR  WHOSE  KTH  COMPONENT 
IS  THE  PROFIT  GAINED  IN  THE  KTH  PRIORITY  LEVEL  SO  FAR  IN 
THE  CURRENT  EXCHANGE  CYCLE. 

13.  PROFN(K)--!S  A  NP -D I  MENS  1 ONAL  VECTOR  WHOSE  KTH  COMPONENT  IS  THE 
PROFIT  IN  THE  KTH  FRIORITY  LEVEL  FOR  THE  EXCHANGE 

UNDER  CONSIDERATION. 

14.  I  FLAG- -TAKES  ON  A  VALUE  OF  1  IF  AN  EXCHANGE  IS  PROFITABLE; 

0  OTHERWISE. 

15.  JFLAG - -  TAKES  ON  A  VALUE  OF  1  IF  AN  EXCHANGE  IS  FEASIBLE;  0  OTHEPW I 
>6.  CANOl 1) --TAKES  ON  THE  INDEX  NUMBER  OF  THE  I TH  VARIABLE 

IN  THE  FITBACK  SET. 


XCXXXXX^XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXfcxXX 


CxxxrxCURRENT  DIMENSION  STATUS 
C 


c 

1  . 

NUMBER 

OF 

GOALS:  200 

c 

2 

NUMBER 

OF 

PRIORITY  LEVELS: 

3 

C 

c 

3. 

NUMBER 

OF 

BUDGET  PERIODS  : 

1  0 

(L 

c 

g- 

4  . 

NUMBER 

OF 

0-1  VARI ABLESf ALTERNATIVES) 

lx 

C 

5. 

NUMBER 

OF 

ALTERNATIVE  GROUPS:  150 

r  x  x  x  x  x  x 


'XXKXXXXXXXKXXXXXXl 


txxxxxxxxxxxxxxx 


ttmititmxixxxxixxx 

RAM/VM  WAS  DEVELOPED  AND  WRITTEN  AT 

ANALYTIC  SERVICES.  INC 
(TACTICAL  DIVISION) 

400  ARMY-NAVY  DRIVE 
ARLINGTON,  VIRGINIA  22202 

(703)  979-0700 
AV  225-5640 

KXXXXXYXXXXXXXIXXxXXXXXxXXXXXKXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXkxx 


DIMENSION  A ( 475 ) , R ( 475 ) 

INTEGER  OV, HV, 0V1 . 0V2 
INTEGER  PR( 475) , W(475) 

COMMON  /COMM  1 /  SL (  1 0 ), C ( 4 75 ,  1 0 ), NPER , JFLAG , SLACK (  1 0 ) 
COMMON  /C0MM2/  JS(150),JL 

COMMON  /COMM 3/  AH ( 4  75 , 3 ) , PROF ( 3 ) ,  I  FLAG , NP , PROFN ( 3 ) 
COMMON  /C0MM4/  IGN(  150),  INC<  4  75 ) , CAND (  150), NGR , NVAR 
« . LK , I  LEV ( 200 ) , ACH ( 3 ) 

COMMON  /COMM 5/  NUMF , OV , JV , KV , LV , MV , HV,  1  OUT  1 ,  | 0UT2 
S  ,  I0UT3,  INI , I N2, IN3, NL, NM, NH,  I  I  , JJ,KK 
a, !A, IB, 1C, IAA, IBB, ICC 
COMMON  /C0MM6/  NS ( 4 75 ) , LL , I GR ( 200 ) 

COMMON  /COMM 7/  INIF 

COMMON  /C0MM6/  B(10) 

COMMON  /C0MM9/  MMLFL 

READ (10,501)  NVAR , NG , NP , NPER , NGR , I GS 
READd  0,502)  ( W (  J  )  ,  PR (  J  )  ,  J  = 1 , NG ) 

DO  300  L* 1 , NPER 

300  READ (10,503)  ( C ( I , L > , I = 1 , NVAR ) 

READ (10, 502 )  ( I  OR (  I  ) ,  I  =  1 , NVAR ) 

READd 0,502)  (ILEV(I),I  «  1 , NVAR ) 


35 


READ < 10, 503)  (B(L),LS1 , NPER ) 

501  FORMAT (1615) 

502  FORMAT (1615) 

503  FORMAT < 10F8.0) 

996  FORMAT ( '  ‘,2515) 

C 

C«*SECT10M1 . --ESTABLISH  A  GOOD  INITIAL  SOLUT I  ON- CHOOSE  MOST  COST  EFFECTIVE 
C  SET  OF  OPTIONS  UNTIL  FUNDS  ARE  EXPENDED. 

C 

C*  *F  I RST  FIND  THE  AVERAGE  PROPORTION  OF  AVAILABLE  FUNDS  USED  BY  EACH  VARIABLE  I 
C 

C  1 .  CALCULATE  R ( I ) 

C 

DO  I  1*1, NVAR 

rc  n*o.  o 

DO  2  L  *  1 , NPER 

R( ) ) =R( 1 1 + ( C( I ,L)/BCL) ) 

2  CONTINUE 

R( I  I  =  RC I  ) /NPER 
1  CONTINUE 
C 

C*  * COMPUTE  (BENEFI T(S) /AVERAGE  COST)  VECTOR  FOR  ALL  OPTIONS, 

C 

C  2.  CALCULATE  AHC I ,KI 
DO  4  K=1 , NP 
DO  4  1=1, NVAR 

AHC »,K)  *  0.0 

4  CONTINUE 

DO  3  J  =  1 , NG 

READ  (10,503)  (A(I),I  =  1 , NVAR ) 

K  =  PRC J ) 

DO  5  1=1, NVAR 

IFC 1GS.EQ. 1 . AND.K.EQ. 1 )  GO  TO  560 
GO  TO  561 

560  AH ( I , K ) = A  <  I  ) 

GO  TO  5 

561  CONTINUE 

AA  =  ( A ( I )*W( J) )/R( I ) 

AH ( 1 , K )  =  AHC I ,K)  +  AA 

5  CONTINUE 

3  CONTINUE 
C 

C«*OETERMINE  INITIAL  SOLUTION. 

C 

C* * ADD  A  DUMMY  VARIABLE  TO  INSURE  THAT  1:1  EXCHANGES  WILL  BE  MADE 
C  WITH  LEAST  BENEFICIAL  OPTION. 

C 

ISIZ*1 

IFC ISIZ.NE.O)  GO  TO  907 

NVAR=NVAR+ 1 

NGR=NGR+1 

DO  905  K=1 , NP 

AH  C  NVAR , K ) =0 . 

905  CONT I NUE 
IGRCNVAR) =NGR 
I  LEV (NVAR )  =  1 

DO  906  L* 1 , NPER 
CCNVAR, L)  =  1000. 

906  CONTINUE 

907  CONTINUE 
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«* * ***NOW  CHOOSE  THE  OPTION  WITH  THE  LEXICOGRAPHIC  MAXIMUM  (BENEFIT/COST) 
VECTOR  FOR  EACH  SUBSET  OF  MUTUALLY  EXCLUSIVE  OPTIONS. 

INIF  *  1 
LL  »  0 

DO  6  M  *  1 , NGR 
MAX=0 

DO  7  1*1. NVAR 

I F( 1GR ( I )  .NE.  M)  GO  TO  7 
INCC I >=0 
I  V=  I 

I F ( MAX . EQ . 0 '  GO  TO  101 
CALL  COMPARE  CIV,0V,IN1F) 

IFlINCdl.EO  0)  GO  TO  102 

LL=LL+1 

NS(LL)=OV 

OV  =  I 

GO  TO  7 

102  LL  =  LL  •*  1 
NS(LL)  =  I 
GO  TO  7 

101  CV=I 

I NC  t I  ) *  1 
MAX—  1 

7  CONTINUE 

JS(M)=OV 
6  CONTINUE 

INIF=0 

«*NOW  RANK  THE  SET  CONTAINING  THE  MAXIMUM  (BENEFIT/COST)  VECTOR 

OPTIONS  FOR  EACH  ALTERNATIVE  GROUP  IN  DESCENDING  ORDER  OF  ( BENEF I T /COST ) 
VECTOR  MAGNITUDE. 

DO  8  M  =  2 , NGR 
N=M 

103  M0=JS(N-1) 

MNsJS(N) 

CALL  COMPARE (MN, MO, INIF) 

I  F  (  1  FLAG  .  EO.  0)  GO  TO  8 
INTER  =  JS ( N -  1  ) 

JSCN-1 )=JS(N> 

JS  ( N )  =  I NTER 
N  =  N-1 

I  F ( N-  1 )  6,6, 103 
B  CONTINUE 
JL=NGR 

*  *CHECK  TO  SEE  IF  THE  INITIAL  SOLUTION  CONFORMS  TO  ALL  FUNDING  CONSTRAINTS 
IF  NOT,  REMOVE  ENTRY  WITH  SMALLEST  BENEFIT  VALUE  AND  PLACE  IN  SET  OF 

NON-FUNDED  OPT  1 ONS - -REPEAT  UNTIL  BUDGET  FEASIBILITY  IS  REACHED. 

***CHECK  (JS)  FOR  FEASIBILITY  AND  DELETE  BOTTOM  ENTRY  IF  NOT  FEASIBLE 

104  DO  9  L  *  1 , NPER 

cc=o. 0 

DO  10  M  ■  1 , JL 
I  * JS ( M ) 

CC*CC+C< I , L) 

IF(CC.GT.B(L) )  GO  TO  105 
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CONTINUE 

SLACK ( L 1 =  B(L) -CC 
9  CONTINUE 
SO  TO  106 

105  11=  JS( JL) 

INCH  I  )=0 
JL=JL-1 
LL=LL+ 1 

NS  ILL)  =  1  1 
GO  TO  104 
C 

C*  *EXCEPT  FOR  A  PRIORITY  ONE  GOAL  INDICATING  THOSE  SUBSETS  WHICH  MUST 
C  RECEIVE  NON-ZERO  FUNDING  (IF  PRESENT),  RERANK  OPTIONS  IN  BOTH  SETS 
C  (IN  THE  SOLUTION  AND  OUT  OF  THE  SOLUTION)  IN  RESPECTIVELY,  ASCENDING 
C  AND  DESCENDING  ORDER  OF  BENEFIT  VALUE. 

C 

106  DO  11  K  «  1, NP 
DO  11  I  =  1, NVAR 

I F  (  IGS  EQ  1  AND  K. EO  1 )  GO  TO  11 
AH ( I ,K) =AH( I , K) *R< I ) 

1 1  CONT I NUE 
CALL  RERANK 

500  CONTINUE 
KKFL=0 
C 

C  *  *  NOW  USING  ANY  SLACK  FUNDS  CHECK  THOSE  SUBSETS  OF  MUTUALLY  EXCLUSIVE 
C  OPTIONS  WHICH  ARE  NOT  IN  THE  INITIAL  SOLUTION  TO  SEC  IF  _*_N_Y  MEMBER 
C  CAN  BE  FIT  BACK  INTO  THE  INITIAL  SOLUTION.  THESE  ARE  IDENTIFIED  IN 
C  THE  OUTPUT  AS  "F1TBACK  VARIABLES"  IF  PRESENT. 

C 

CALL  FITBACK(KKFL) 

* *N0W  OUTPUT  INITIAL  SOLUTION. 

I OFL* 1 

CALL  OUTPUT! I OFL) 

*****  *  * SECT  I  ON  2  FIRST  EXCHANGE ********  * 

*  *  I N  THIS  SECTION  2:1  AND  1:1  EXCHANGES  ARE  MADE  BETWEEN  THE  JS  (FUNDED)  SET 
AND  THE  NS  (NOT  FUNDED)  SET. 

* *NOW  TEST  IF  THE  LAST  2  MEMBERS  OF  THE  RANKED  NS  LIST  BELONG  TO  THE  SAME 
MUTUALLY  EXCLUSIVE  GROUP.  IF  SO  -  - SET  MMFL  TO  THE  INDEX  NO  OF  THAT  GROUP 

MMLFL  *  0 
JE=NS(LL1 
LM1 =LL- 1 
JF=NS(LM1 ) 

IFCIGR(JE)  EQ.IOR(JF))  MMLFL  *  IGR(JE) 

I  I  J=0 

116  CONTINUE 
II J=I I J+l 

»*ZERO  OUT  EXCHANGE  PROFITABILITY  INDICATOR. 

DO  1 2  K  *  1 , NP 
PROF ( K ) *  0 . 0 

12  CONTINUE 
C 
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"NOW  SET  UP  2:|  EXCHANGE 

NV2=NVAR+2 
I  N I  F  =  3 

DO  13  NL=1 , LL 
IDUH=0 
NH=NL+1 
J  JFL* 1 

"IF  LL  LIST  IS  EXHAUSTED- -EX  I T  EXCHANGE  CYCLE. 

109  IF(NH.GT.LL)  GO  TO  13 
HV  =  NS(NH) 

LV'NSCNLI 

*  *  TWO  ENTERING  ALTERNATIVES  MAY  NOT  BELONG  TO  THE  SAME 
MUTUALLY  EXCLUSIVE  GROUP. 

I F ( I GR ( HV )  ,EQ.  IGR(LVI)  GO  TO  107 
GO  TO  108 

107  NH=NH+1 
GO  TO  109 

108  CONTINUE 

"DETERM I NE  COMBINED  CONTRIBUTION  TO  ALL  GOALS  J,  OF 
TWO  "ENTERING"  ALTERNATIVES. 

DO  14  J  =  1 , NP 

AH  C  NV2 , J1 =AH( HV , J ) ♦ AH ( LV , J ) 

14  CONTINUE 

"DETERMINE  COMBINED  COST  IN  ALL  BUDGET  PERIODS  L,  OF 
TWO  "ENTERING"  ALTERNATIVES. 


DO  15  L*  1  , NPER 
C(NV2,L)=C(HV,L)+C(LVJL) 

15  CONTINUE 

«*NOW  LOOK  FOR  2:1  EXCHANGES  WITH  MEMBERS  OF  JS  SET. 

DO  16  I  I « 1 , JL 
0V= JSC  I  I  ) 

IS* IGR(LV) 

IX= IGRCHV) 

* 'EXCHANGE  MUST  BE  FEASIBLE  WITH  RESPECT  TO  MUTUALLY 
EXCLUSIVE  SUBSETS. 


I F ( IGNC IS) . NE . 0. ANO. IGRCLV) . NE . IGR(OV) )  GO  TO  16 
IF< IGNC IX)  NE  0. AND. 1GRCHV) . NE  IGRCOV) )  GO  TO  110 
NV«NV2 


"TEST  EXCHANGE  FOR  PROFITABILITY  (MUST  BE  MORE 
THAN  ANY  OTHER  FEASIBLE  EXCHANGE  TRIED  IN  21 


PROFITABLE 
CYCLE) . 


CALL  COMPARE (NV,OV, INI F) 

I  F  (  I  FLAG .  EO  0)  GO  TO  1  1  1 
C 

C«»TEST  EXCHANGE  FOR  BUDGET  FEASIBILITY. 
C 
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CALL  FEAS l OV , NV ) 

IF< JFLAG.EQ.O)  GO  TO  110 
NUMF  =  2 
GO  TO  112 
C 

C*  *  I F  ANY  2:1  EXCHANGE  WITH  HIGHER  RANKING  OF  2  "ENTERING" 

C  VARIABLES  HAS  BEEN  UNPROFITABLE,  OR  IF  ALL  1:1  EXCHANGES 
C  WITH  HIGHER  RANKING  OF  2  “ENTERING"  VARIABLES  HAVE  BEEN 
C  UNPROF  1  TABLE,  SKIP  1:1  EXCHANGE. 

C 

110  IFtJJFL.GT.il  GO  TO  16 
I  Ft  IDUM  EQ  .LV)  GO  TO  1 6 
NV  =  LV 

** ASSUME  1 : 1  EXCHANGE  FEASIBILITY  WITH  RESPECT  TO  MUTUALLY  EXCLUSIVE 
GROUPS. 

IFtNV  EQ.LNM.AND  OV.EQ.LNN)  GO  TO  1 6 

« *CHECK  1 :  1  EXCHANGE  FOR  PROFITABILITY  AND  BUDGET  FEASIBILITY. 

CALL  COMPARE  (  NV  ,  OV  ,  I  N I  F  ) 

LNM^NV 
LNN— OV 

l F ( IFLAG.EO  0)  GO  TO  16 
CALL  FEAS  C  OV , NV 1 
I F ( JFLAG  .  EQ  0)  GO  TO  16 
NUMF=1 
GO  TO  112 

**AFTER  NON-PROF  1  TABLE  2:1  EXCHANGE  HAS  BEEN  TRIED--1F  INDEX  OF  HIGH 
RANKING  "ENTERING"  VARIABLE  1 S  1  ,  OP  IF  HIGH  RANKING  "ENTERING" 
VARIABLE'S  MUTUALLY  EXCLUSIVE  GROUP  IS  REPRESENTED  IN  THE  FUNDED 
SET,  INCREMENT  INDEX  OF  HIGH  RANKING  "ENTERING"  VARIABLE  AND 
CONTINUE.  IF  NOT,  INCREMENT  INDEX  OF  LOWER  RANKING  "ENTERING" 
VARIABLE  AND  CONTINUE 

111  IF< I  1  . EO. 1 )  GO  TO  13 

IF< IGN< IS)  .EQ  1 )  GO  TO  13 
NH=NH« 1 
JJFL-2 
GO  TO  109 

»IF  A  PROFITABLE  AND  FEASIBLE  EXCHANGE  WAS  FOUND,  CHANGE  CRITERION 
FOR  PROFITABILITY,  AND  SET  UP  PROVISIONAL  EXCHANGE  VARIABLES 

112  DO  1 7  K  *  1 , NP 
PROF ( K ) =  PROFN ( K ) 

17  CONTINUE 
I A  *  I  I 
I OUT'OV 
INI  «  LV 
IAA  «  NL 

I F  <  NUMF . NE . 2 )  GO  TO  113 
IN2  *  HV 
IBB  •  NH 
BO  TO  111 

113  IN2  >  0 

1 6  CONT I NUE 

I DWN*LV 
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©0  TO  107 
13  CONTINUE 

DO  18  K= 1 , NP 

«*IF  NO  PROFITABLE  AND  FEASIBLE  EXCHANGE  WAS  FOUND- -F l TBACK  USING 
REMAINING  SLACK  AND  OUTPUT  SECOND  STAGE  SOLUTION. 

IF  ( PROF C K ) . GT  0 . 0 )  GO  TO  114 
1  8  CONT 1 NUE 
KKFL  =  1 

CALL  FI TBACK (KKFL) 

I0FL=2 

CALL  OUTPUT ( I OFL) 

IF< ISI2.EQ  1 )  GO  TO  810 

**MAKE  MOST  PROFITABLE  FEASIBLE  EXCHANGE  FOUND  AND  BEGIN  CYCLE  AGAIN 

114  INC (l OUT  1*0 
INCC INI ) = 1 
I NTER3=  JS ( I  A) 

JS< I  A) -NS( 1AA) 

N=JS( I  A) 

I J*IGR(N) 

NS< I AA )  =  I NTER3 
I  P=  1 GR ( INTER3) 

IGNC IP)=0 
IGNC I J) =1 

I F< IN2. EO. 0)  GO  TO  115 

LLL*0 

LL'LL-1 

DO  396  I  a  1 , LL 

J  =  l-H 

I F< NS ( I ) . EQ . I N2 )  LLL=1 
I F<  LLL . EQ .  1 )  NS ( I  )=NS< J) 

396  CONTINUE 

I  NC ( 1 N2 ) -  1 
JL*JL+1 
JS<  JL )  *  I  N2 
LX* IGR( IN2) 

I GN  t  LX )  =  1 
1  1 5  CALL  RERANK 

DO  28  L=  1 , NPER 
CC*0  0 

DO  29  M=1 , JL 
I «JS(M) 

CC«CC+C( I , L) 

29  CONTINUE 

slack  c  l  >  *b ( l ) -cc 

8  CONTINUE 
GO  TO  116 
10  I OFL*  3 

CALL  OUTPUT (I OFL) 

CLOSE (8) 

CLOSE (101 

STOP 

END 

a  *  a • SUBROUT lNES***»**»**»**»*«»*«*a*a»***«»» 

SUBROUTINE  FEAS(LOV.NV) 
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••CHECKS  FOR  BUDGET  FEASIBILITY. 

COMMON  /COMM  1 /  SL <1 0 ) , C ( 4  75 , 1 0 ) , NPER , JFLAG , SLACK M 0 ) 
COMMON  /COMM7/  INIF 
DO  1  L  •  1  , NPER 
SLID  =  SLACK  (  L  > 

SL<  L ) =SL  t  L ) »C ( LOV , L ) ~C ( NV , L ) 

SLF=SL ( L ) + . 0005 
I F< SLF  )  10,1,1 
1  CONTINUE 
JFLAG=1 
GO  TO  11 
10  JFLAG=0 
1  1  RETURN 
END 


SUBROUTINE  RERANK 
C 

C**REORDERS  PROJECTS  IN  JS  AND  NS  AFTER  EACH  EXCHANGE. 

C 

COMMON  /COMM2/  JS(150),JL 
COMMON  /C0MM7/  INIF 

COMMON  /C0MM3/  AH ( 475 , 3 ) , PROF ( 3 ) ,  I  FLAG , NP , PRCFNC 3 ) 
COMMON  /C0MM6  '  NS ( 475 ) , LL ,  1 GR ( 200 ) 

INIF  *  O 

I F <  JL • LT . 2 )  GO  TO  71 

C**r»»»**»*******r****»**(v;s)****«*«******** 

DO  70  M-2, JL 
N=M 

700  M0=JS<N-1) 

MN=JS(N) 

CALL  COMPARF ( MN , MO , 1 N I F ) 

I F< I  FLAG . EO  1  )  GO  TO  70 
I NTER  =  JS ( N -  1  ) 

JS<  N- 1 )=JS(N) 

JS<  M )  =  I NTER 
N  =  N-1 

IF<M- 1 )  70,70,700 

70  CONT I NUE 

71  CONTINUE 

C****»**»************»***( NS )*************•* 

DO  57  M  =  2, LL 
N=M 

604  MO~NS ( N -  1 ) 

MN=NS(N) 

CALL  COMPARE  t  MN , MO ,  1 N 1 F ) 

I  F <  1  FLAG  .  EG  .  0 )  GO  TO  57 
I NTER  =  NS  C  N- 1 ) 

NS<  N- 1 )  «  NS ( N ) 

NS<  N )  =  INTER 
N  =  N-  1 

IF<N-1)  57,57,604 
57  CONTINUE 
RETURN 
END 
C 


SUBROUTINE  FITBACK  (KKFL) 

C 

C**US£S  UP  BUOGET  SLACK  TO  FIT  BACK  PROJECTS. 

C 

COMMON  /COMM1 /  SL( 1 0 >, C< 475, 1 0 >, NPER, JFLAG, SLACK ( 1 0 > 
COMMON  /COMM 2/  JS(150),JL 

COMMON  /COMM3/  AH ( 475, 3 ) , PROF ( 3 ) ,  I  FLAG, NP, PROFN ( 3 ) 
COMNON  /COMM4/  1 GN I  1 50 > ,  I NC ( 475 ) , CAND I  1 50 > , NGR , NVAR 
4 , LK , I  LEV  1 200 ) , A OH ( 3 ) 

COMMON  /C0MM6/  NS ( 475 ) , LL , I GR ( 200 ) 

COMMON  /COMM 7/  IN1F 
DO  15  L=  1  , NPER 
SL<  L ) = SLACK ( L ) 

15  CONTINUE 

DO  11  M  = 1 , NGR 
IGNCM) =0 

11  CONTINUE 

DO  10  1 =1 , JL 
N*JS( I ) 

M'IGR(N) 

I GN  C  M )  =  1 
10  CONTINUE 
LK  =  0 

DO  12  1 = 1 , LL 
I  I =  NS< I  ) 

MP  =  0 

DO  19  K=  1  , NP 
MP=MP  *  AH< I  I , K ) 

19  CONTINUE 

IF(NP.EO.O)  GO  TO  12 
M* 1 GR (111 

I F< IGM(M) . NE. 0)  GO  TO  12 
DO  13  L=1,NPER 

IF<C( I  I , L) . GT. SL(L) )  GO  TO  12 

1 3  CONT I NUE 
LK=LK+1 
CAND ( LK ) *  1  I 

DO  14  L=1,NPER 
SL<L)sSLCL)-C( I  I ,L) 

14  CONTINUE 

12  CONTINUE 

I F < KKFL  .EQ.  0  OR.  LK  .  EQ  .  0)  GO  TO  17 
DO  18  I  *  1 , LK 
JJ  *  CAND ( I ) 

INCCJJ)  *1 
JL  =  JL  ♦  1 
LL  =  LL - 1 
JS<  JL )  *  JJ 
JK  *  IGR(JJ) 

IGNCJK)  =1 
1 8  CONT I NUE 
17  CONTINUE 
RETURN 
END 
C 

. . . 

c 

SUBROUTINE  COMPARE (IN, 10, INIF) 


I 
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C* ‘CHECKS  FOR  PROFITABILITY. 

C 

COMMON  /COMM 3/  AH ( 475 , 3 ) , PROF ( 3 > ,  I  FLAG , NP , PROFN ( 3 ) 
COMMON  /COMM 4/  1 6N (1 50 ) .  1 NC C 4  75 ) , CANO ( I  50 ) , NGR, NVAR 
6 , LK , I  LEV ( 200 ) , ACH ( 3 ) 

COMMON  /C0MM2/  JS(150),JL 
I F< INI F  .NE.  1)  GO  TO  11 
DO  1  K  «  1 . NP 

IF<AH(IN,K>  -  AH(JO,K>)  2,1,3 

1  CONTINUE 

2  GO  TO  10 

3  INC (IN)  =  1 

I NC (10)  *  0 
GO  TO  10 

11  IF< INI F  .NE.  0)  GO  TO  12 
DO  4  K  =  1 , NP 

I F  <  AH ( I N , K )  -  AH ( I  0 , K ) )  5,4,6 

4  CONT 1 NUE 

5  I  FLAG  =  O 
GO  TO  10 

6  I  FLAG  =  1 
GO  TO  10 

12  I F< I N l F  .NE.  3)  GO  TO  10 
DO  7  K  =  1 , NP 

PROFN ( K )  =  AH ( 1 N , K ) -AH ( 1 0 , K ) 

7  CONTINUE 

DO  8  K  ‘  1 , NP 

IF<FROFN(K) -PROF(K) )  16,8,20 

8  CONTINUE 

18  I  FLAG  =  0 

GO  TO  10 
20  I  FLAG  =  1 

10  RETURN 

END 
C 

c********************************************** 

c 

SUBROUTINE  OUTPUT ( 1 OFL ) 

C 

C» ‘WRITES  OUT  THE  SOLUTION. 

C 

COMMON  /COMM4 /  I GN (1 50 ) , I NC ( 475 ) , CAND ( 1 50 ) , NGR , NVAR 
4 , LK , 1  LEV (200) ,ACH(3) 

COMMON  /C0MM2/  JS(150),JL 

COMMON  /C0MM3/  AH ( 475 , 3 ) , PROF ( 3 ) .  1  FLAG , NP , PROFN ( 3 ) 
COMNON  /C0MM6/  NS ( 475 ) , LL , 1 GR ( 200 ) 

COMMON  /COMM 1 /  SL ( 1 0 ), C ( 475 , 1 0 ), NPER , JFLAG , SLACK ( 1 0 ) 
COMMON  /COMM 8/  B(10> 

COMMON  /COMM 9/  MMLFL 
I F< IOFL.GT  1 )  GO  TO  973 

OPENte, FORM= "FORMATTED" , ACCESS* " SEQUENT  I AL " , MODE* "OUT " , 
4CARR I AGE=  TRUE. , F I LE= " F 1 LEOUT " ) 

973  WR1 TE ( 8 , 600 ) 

DO  398  K= 1 , NP 
398  ACHCK ) >0 . 0 

I F< IOFL.NE  1 )  GO  TO  25 
WR1 TE ( 8 , 601 )  I OFL 
WRITE (8, 602) 

WR1 TE ( 8 , 603 ) 

DO  400  I » 1 , JL 
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I ! « JS( I  ) 

WRITE (8, 600 )  JSC  1) , 1  OR ( I  I  ) ,  ILEVC I  1  ) 

DO  400  K=1 , NP 

ACH C K ) 1 ACH ( K ) +AH ( I  I ,K) 

400  CONTINUE 

I F <  LK . EQ . 0 )  SO  TO  777 
WRI TE ( 8 , 605 ) 

WR1 TE<  8, 603 ) 

DO  401  1*1, LK 
I  I *CAND<  I ) 

WR1 TE ( 8  604 )  l I  , I GR  C 1 1  ) ,  I  LEV (II) 

DO  401  K=1 ,NP 
ACH(K)=ACH(K)+AH(  I  1  ,K) 

401  CONTINUE 
GO  TO  777 

25  IF< 10FL . NE . 2)  GO  TO  50 
WR1 TE ( 8 , 60 1 )  I OFL 
WR1 TE ( 8 , 602 ) 

WR1 TE ( 8 , 603 ) 

DO  403  1 *1 , JL 
I  I *JS( I  ) 

WRITE (8. 604)  JS ( 1 ) , I GR ( I  I  > ,  !LEV( I  I ) 

DO  403  K=1 , NP 
ACH(K)=ACH(K) + AH (  I  I  ,K) 

403  CONTINUE 
GO  TO  777 

50  DO  405  K*1 ,NP 

I F< PROF ( K )  . GT . 0 .  )  GO  TO  794 
GO  TO  795 

794  CONTINUE 

405  CONTINUE 

WR1 TE ( 8 , 601 )  I OFL 
WR1 TE ( 8 , 602 ) 

WRITEC6, 603) 

DO  406  I *1 , JL 
I  I = JSC  I  ) 

IF< JS< I ) -EQ. 0)  GO  TO  406 

WRITE! 8, 604)  JS ( I) ,  I GR ( I  1 ) ,  ILEV( I  I  ) 

DO  407  K*1 ,NP 

ACH ( K ) * ACH( K ) + AH ( I  I ,K> 

407  CONTINUE 

406  CONTINUE 
777  WRI TE ( 8 , 606  > 

DO  402  K=1 ,NP 

402  WRI TE ( 8 , 607 )  K , ACH ( K ) 

795  CONTINUE 

I F < I OFL . NE . 3 )  GO  TO  909 
DO  411  L* 1 , NPER 
CC«0.0 

DO  417  M*1 , JL 
I  * JS ( M ) 

CC*CC+C( I.L) 

417  CONTINUE 

SLACK ( L  >  »B ( L ) -CC 

WRI TE ( 8 , 609 )  L, SLACK ( L ) 

4 1 1  CONT I NUE 
909  CONT I NUE 
RETURN 

600  FORMAT ( ' 1 ' , 35X , ' MULT I PLE  OBJECTIVE  RESOURCE  ALLOCATION 
«  SOLUTION  SYSTEM  OUTPUT1) 


I 


! 


i 


i 
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601  FORMAT! • 1 ' ,55X, ‘OUTPUT  FROM  PHASE  ‘,11) 

602  FORMAT! 'O' ,45X, 'THE  FOLLOWING  VARIABLES  ARE  IN  THE  SOLUTION') 

603  FORMAT! ' O' , 17X, 'VARIABLE  I NDEX ' , 1 6X , ' ALTERNAT I VE  GROUP  NUMBER' ,  16X, 
6 ' FUND I NG  ALTERNATIVE  NUMBER ' ) 

604  FORMAT (  '  ' , 23X ,  I  3 , 30X ,  I  3 , 38X , I  2 ) 

605  FORMAT ('0‘, 59X , ’ F I TBACK  VARIABLES') 

606  FORMAT! 'O' , 15X, 'ACHIEVEMENT  VECTOR') 

607  FORMAT !  '  ' , 20X ,  ' PR  1  OR  I TY  'll, 5X, F20 . 4 ) 

609  FORMAT!  ' 0 ', 40X,  ' SLACK  REMAINING  IN  PERIOD  ' , I  2,  '  :  ' , 5X, F20 . 6 ) 

END 
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I.  INTRODUCTION 


This  volume  is  one  of  four  that  document  ANSER's  develop¬ 
ment  of  R&D  resource  allocation  methodology  (RAM)  for  the 
Director  of  Program  Integration,  AF/RDX.  Volume  1  provides 
an  overview  of  the  work  and  its  applications.  Volume  2  des¬ 
cribes  the  RAM  technique  and  how  to  use  the  general-purpose 
computer  programs  that  incorporate  it.  Volume  3  describes  how 
to  use  the  interactive  computer  program  developed  for  use  of 
the  RAM  within  AF/RDX,  and  Volume  4  describes  the  way  in  which 
we  tested  its  computational  performance.  Each  volume 
emphasizes  some  particular  aspect  of  our  research  and  can  be 
read  independently  of  the  others. 

This  volume  describes  the  computer  software  we  wrote  to 
enable  AF/RDX  to  use  the  RAM  algorithm  with  its  in-house  data 
base  of  Air  Force  R&D  programs.  It  is  designed  for  that 
computer  system,  specific  hardware,  and  data  base;  consequently, 
the  software  is  not  readily  transferable  to  other  systems. 
Nevertheless,  other  readers  may  also  find  the  software  design 
potentially  useful  for  decision  making  in  resource  allocation. 

Our  goal  in  producing  the  software  was  to  demonstrate 
the  relative  ease  with  which  it  could  be  used  to  obtain  an 
investment  strategy.  The  user  of  the  software  needs  only  a 
basic  knowledge  of  computer  programming.  By  merely  specifying 
on  the  computer  terminal  the  available  resources  as  a  function 
of  time,  the  user  receives  from  RAM  the  list  of  programs 
providing  the  greatest  benefit.  (This  presumes,  of  course, 
that  the  program  alternatives  have  been  evaluated  in  advance 
with  respect  to  the  chosen  objectives.)  To  determine  the 
impact  of  funding  cuts  or  enhancements,  the  user  simply  has 
to  type  in  some  data.  One  of  the  available  outputs  is  a 
graphic  display  of  the  benefits  and  costs  for  the  various 


investment  strategies  generated.  This  display  enables  the 
user  to  see  whether  the  strategies  are  at  "efficient"  points 
on  the  cost/benefit  curve. 

In  Chapter  II,  we  describe  the  interactive  portion  of 
the  software.  Using  the  software  does  not  require  an  under¬ 
standing  of  RAM,  but  if  interested,  the  reader  may  refer  to 
Volume  2  for  an  explanation.  The  user  may  desire  to  make  other 
parts  of  the  data  base  interactive  or  to  produce  graphic 
displays  other  than  those  we  have  designed.  Chapter  III,  which 
serves  as  a  programmer's  guide  for  those  modifications,  re¬ 
quires  detailed  knowledge  of  computer  programming.  Chapter 
IV  contains  the  appropriate  computer  codes . 

At  the  time  this  work  was  completed,  the  anticipated 
"benefit"  data  were  not  available  in  the  official  data  base. 
Consequently,  to  demonstrate  the  software,  we  substituted 
a  simple  procedure  that  generates  random  benefit  data.  If 
appropriate  data  became  available,  this  procedure  could  be 
easily  changed  using  the  information  in  Chapters  III  and  IV. 
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II.  USER'S  GUIDES 


A.  User's  Guide  to  the  Program  NOW 
1.  Background 

NOW*  is  a  computer  program  written  in  the  PL/1  programming 
language;^  it  is  on  file  at  the  Air  Force  Data  Services 
Center's  Multics  computer  system.  NOW  is  the  master  program 
driving  a  set  of  subroutines,  the  purpose  of  which  is  to 
determine  and  compare  investment  strategies  for  the  selection 
of  funded  program  element  (PE)  alternatives  within  a  mission 
area. 

The  information  necessary  for  the  execution  of  the  program 
is  part  of  a  data  base  managed  by  AF/RDX  on  the  Multics. 

The  user  must  obtain  the  required  Multics  clearances  to  access 
the  data  base. 

The  NOW  user  should  be  aware  of  the  general  nature  of  the 
R&D  data  base.  The  data  are  grouped  into  10  mission  areas, 
indicated  by  the  number  codes  000,  100,  200,  300,  400,  500, 

600,  700,  800,  and  900.  An  eleventh  category,  "off,"  is  also 
listed.  The  "off"  category  identifies  the  official  data  base, 
which  contains  official  data  in  the  10  mission  areas.  The 
official  data  base  contrasts  with  a  working-level  data  base 
that,  at  any  given  time,  may  be  in  a  state  of  flux.  The 
"off"  data  base  contains  all  R&D  program  elements.  Users  of 
NOW  will  normally  access  the  official  R&D  data  base.  A 


♦Names  of  computer  terms  in  this  report  are  in  upper  case 
except  where  they  are  to  be  literal  input  to  the  computer 
system.  Such  inputs,  when  described  in  the  test,  are  given 
in  quotes. 

^With  FORTRAN  language  subroutines. 
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second  data  base,  the  "sc"  data  base,  also  exists,  but,  at  the 
time  of  this  writing,  is  not  in  use. 

2.  Program-User  Interaction 

The  following  is  a  step-by-step  procedure  for  use  of  the 
interactive  portion  of  the  program.  (See  Figure  1  for  inter¬ 
actions  in  an  actual  run . ) 

You*  are  now  assumed  to  be  within  the  Multics  facility 
and  to  have  a  copy  of  program  NOW.  You  must  now  log  on  to  the 
system  at  a  SECRET  level.  If  your  name  is  Smith,  the  appro¬ 
priate  log-on  format  is  as  follows: 

"1  Smith  -auth  s" 

Initiate  execution  of  program  NOW  by  entering  the  word  "now" 
via  the  terminal  keyboard.  The  system  will  respond  by  re¬ 
questing  your  Multics  personal  ID.  For  Smith,  the  appropriate 
response  is  "Smith,"  not  "Smith  -auth  s". 

After  entry  of  your  personal  ID,  the  program  asks  a  series 
of  questions  intended  to  determine  your  inputs  to  a  resource 
allocation  algorithm.  The  program  first  asks  whether  you 
desire  the  rd  or  sc  data  base.  Respond  by  entering  "rd"  or 
"sc".  In  response,  the  program  lists  the  codes  indicating 
the  mission  areas  to  which  you  have  clearance  to  access.  The 
mission  areas  corresponding  to  the  number  codes  are  as  follows: 

000  Programs  Not  Assigned  to  a  Mission  Area 

100  Strategic  Offense 


*  For  simplicity,  "you"  is  synonomous  with  user  throughout 
the  rest  of  this  chapter. 
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FIGURE  1 

PROGRAM-USER  INTERACTION 


now 

Enter  your  Multics  person_id  Clary 
rthat  dataDase?  rd  or  sc?  rd 

you  nave  access  to  the  following  mission  areas* 

000 
I  00 
200 
J00 
400 
500 
oOO 
/GO 
500 
900 
off 

off  data?  yes 

Hhich  mission  area?  if  none,  type  •'none*'.  100 
rthat  a ppropria tion ?  3600 

How  many  years  of  cost  would  you  like  to  consider?  / 

Enter  year,  budget  79  1000000 

Enter  year,  oudget  dO  I0000U 

Enter  year,  Dudget  81  100000 

Enter  year,  budget  82  100000 

Enter  year,  budget  83  100000 

Enter  year,  budget  84  100000 

Enter  year,  budget  85  100000 
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200 


Strategic  Defense 
300  Tactical  Air  Warfare 

400  Space  Launch  and  Orbital  Support 

500  Mobility 

600  Reconnaissance 

700  Command,  Control  and  Communications 

800  Technology  Base 

900  Defense-Wide  Management  and  Support. 

The  program  next  asks  whether  you  wish  to  use  official 
data  with  the  query 

"off  data?" 

It  also  asks  you  to  select  a  mission  area.  Respond  with  one 
of  the  mission  area  codes  to  which  you  have  access.  This 
selection  determines  which  mission  area  the  resource  allocation 
routine  will  consider.  If  you  wish  to  terminate  the  program, 
enter  the  word  "none". 

The  R&D  allocation  process  works  with  the  following  four 
appropriation  categories  and  their  respective  number  codes: 

o  Aircraft  Procurement,  3010 

o  Missile  Procurement,  3020 

o  Other  Procurement,  3080 

o  RDT&E ,  3600. 

Each  program  element  is  stored  in  the  data  base  with,  among 
other  things,  its  associated  appropriation  code  (3010,  3020, 
3080,  or  3600).  Thus,  when  you  select  an  "appropriation," 
a  subset  of  the  program  elements  from  the  selected  mission 
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area  is  designated  for  input  to  the  resource  allocation  pro¬ 
gram.  You  roust  respond  to  the  query:  "what  appropriation?", 
with  one  of  the  four  number  codes.  At  the  present  time,  data 
exist  for  the  3600  appropriation  only. 

You  roust  now  decide  which  budget  years  you  want  the 
resource  allocation  routine  to  consider  and  the  budget  levels 
for  the  selected  years.  For  budget  years,  you  may  designate 
any  set  of  years  from  79,  80,  81,  82,  83,  84,  and  85. 

The  system  will  ask:  "How  many  years  of  cost  would  you  like 
to  consider?"  The  system  will  then  ask  you  to  enter  the 
budget  year  and  budget  level  for  the  selected  years.  You 
should  leave  a  space  between  the  budget  year  and  level.  Note 
that  the  budget  is  entered  in  thousands  of  dollars;  therefore, 
enter  $100,000,  for  example,  as  "100". 

You  have  now  completed  the  necessary  inputs  for  one  exe¬ 
cution  of  the  resource  allocation  program.  Table  1  gives  a 
complete  listing  of  your  input  alternatives. 

TABLE  1 

USER  INPUT  ALTERNATIVES 


Data 

Base* 

Mission 

Area* 

Appropriation* 

Budget  Years* 

Budget  Levels 

M 

— - - 

000 

3600 

79 

Expressed  in 

mM 

100 

80 

thousands  of 

mm 

mum 

3010 

81 

dollars 

Bl 

3020 

82 

400 

83 

500 

84 

600 

85 

1 

700 

1 

800 

■ 

900 

'Choose  only  one. 
^Choose  any  or  all. 


At  this  point,  before  execution  of  the  resource  allocation 
algorithm,  the  system  scans  all  PE  alternatives.  Those 
alternatives  having  zero  funding  levels  for  the  specified 
budget  years  are  not  considered  in  the  resource  allocation 
algorithm.  They  are,  however,  printed  out  for  your  con¬ 
venience. 

After  execution  of  the  resource  allocation  algorithm,  the 
system  displays  those  program  elements  that  the  resource 
allocation  algorithm  selected  for  funding.  It  includes 
some  self-explanatory,  associated  data  base  information. 

Costs  of  each  PE  alternative  for  each  of  the  7  budget  years 
and  benefits  to  the  goals  are  also  provided. 

Note  the  instructions  printed  out  just  before  the  first 
page  of  classified  output.  After  each  page  of  classified 
output  is  printed,  you  must  enter  some  character,  for 
example,  "a".  Then,  if  you  are  using  a  CRT  terminal  and 
desire  a  permanent  output  record,  you  must  make  a  copy  on 
the  Tektronix  4631  Photocopier.  You  must  then  reset  the 
page  and,  finally,  press  the  return  key.  The  photocopying 
and  page  reset  steps  are,  of  course,  omitted  if  you  are  at 
a  hardcopy  terminal.  The  instructions  are  printed  out  only 
once,  but  you  must  execute  this  sequence  after  each  page  of 
classified  material  is  printed. 

The  next  output  is  a  summary  of  the  costs  and  benefits 
of  the  set  of  program  elements  selected  by  the  resource 
allocation  subroutine.  The  total  cost  of  the  selected  pro¬ 
gram  elements  summed  over  all  cost  years  and  the  total 
benefits  for  each,  task*  are  printed  out.  An  example  of  such 
output  follows. 


*  Benefits  for  each  task  means  the  contributions  toward 
achievement  of  the  goals. 


9700.00 


total  cost 

of 

the 

solution 

is 

benef it 

to 

task 

1  - 

268.81 

benefit 

to 

task 

2  - 

230.89 

benef i t 

to 

task 

3  » 

262.54 

benefit 

to 

task 

4  * 

181 .86 

Do  you  want  the  output  from  this  strategy  saved  for  graphs?  Please  answer  yes  or 
yes 

do  you  want  to  generate  more  data  before  constructing  graphs? 
yes 

Select  one  of  the  following* 

Indifferent  database 
2*different  mission  area 
3«different  appropriation 

4*dlfferent  budgets  for  years  currently  considered 

indifferent  years  of  cost  data 

o»stopl 

What  database?  rd  or  sc?  rd 

you  have  access  to  the  following  mission  areas* 

000 
I  00 
200 
JOO 
400 
500 
600 
100 
dOO 
900 
off 


You  must  now  decide  whether  you  want  the  results  of  the 
resource  allocation  subroutine  to  be  shown  graphically.  The 
system  will  ask,  "Do  you  want  the  output  from  this  strategy 
saved  for  graphs?"  If  the  answer  is  "yes,"  you  must  then 
decide  whether  to  generate  additional  results  before  con¬ 
structing  graphs  or  to  proceed  into  the  graphics  segment 
of  the  program  with  the  solutions  you  already  have. 

The  system  will  ask,  "Do  you  want  to  generate  more  data 
before  constructing  graphs?"  If  your  answer  is  "yes,"  the 
system  will  display  a  set  of  alternatives  for  the  next 
resource  allocation.  If  your  answer  is  "no,"  the  system  will 
take  you  through  subroutine  GRAPH  before  you  can  try  any 


additional  resource  allocation  strategies.  (See  Section  II .B 
for  subroutine  GRAPH  documentations . ) 


At  some  point,  you  must  decide  on  your  next  resource 
allocation  strategy.  You  are  offered  six  alternatives:  to 
use  a  different  data  base;  to  use  a  different  mission  area 
within  your  current  data  base;  to  use  a  different  appropria¬ 
tion  within  your  current  data  base  and  mission  area;  to  use 
different  budget  levels;  to  use  different  budget  years;  or 
to  exit  the  program.  You  need  only  enter  the  number 
designating  the  desired  option. 

If  you  do  select  the  sixth  alternative  (exit  the  program) , 
then  further  user/program  interaction  will  consist  of  repe¬ 
titions  of  previous  interactions. 

B.  User's  Guide  to  Subroutine  GRAPH 

This  subroutine  enables  you  to  obtain  graphics  output 
that  depicts  the  impact  of  alternative  investment  strategies 
on  the  costs  and  benefits  pertaining  to  a  single  mission  area. 

We  assume  in  this  discussion  that  subroutine  GRAPH  is 
being  called  by  the  NOW  program.  Use  of  subroutine  GRAPH 
under  other  circumstances  is  briefly  discussed  at  the  end  of 
this  section. 

Within  the  context  of  the  NOW  driver  program,  subroutine 
GRAPH  is  automatically  called  after  each  execution  of  the 
resource  allocation  algorithm,  RAM/VM*.  Subroutine  GRAPH 
presents  you  with  a  summary  of  the  allocation  results,  such 
as  the  following: 

*See  Volume  2  tor  explanation  of  RAM/VM. 
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Tkt  let* l  cost  of  tki 
kotfik  to  tnk 
buxuf it  te  took 
booof  it  te  i»sk 
bunuf it  to  took 
buruf it  to  took 
buxufit  to  took 
bonofit  to  took 
bunuf it  te  took 


oe'vtier  10  13.90 
1  •  110.00 

2  •  33*. 00 

3  •  3* • S8 

4  >  Es:9.ee 

5  •  ?**  e: 

6  •  2000.ee 

f  •  4.6e 

•  ■  4.60 


You  are  then  asked  if  you  wish  to  save  the  results  to  be 
plotted  on  graphs.  (The  information  saved  is,  of  course, 
considerably  more  extensive  than  what  is  shown.)  If  you  do  not 
want  to  save  the  results  you  are  returned  to  the  main  pro¬ 
gram.  If  you  do  want  to  save  the  results,  you  are  then  asked 
if  you  want  to  generate  more  data  before  constructing  graphs: 


Tba  lota)  coat  of  thu  aolation 
contribution  to  bonaflt  i 
contribution  to  bonaflt  i 
contribution  to  bonaflt  I 
contribution  to  bonaflt 
contribution  to  bonaflt 
contribution  to  benafit 
contribution  to  banafit 
contribution  to  banof it 


la  13. 90 
aaaiuro  1 
■aaaura  2 
waaura 

■aaaura 
■aaaura 


lie.** 

33e.ee 

30.58 

22lS.be 

?ee.e: 

2«ee . ee 

4.60 

4.60 

aavad  for  grapka7 


Do  you  want  tba  output  froa  tkia  atratag. 

So  you  want  to  gonarata  ooro  data  bofora  constructing  graphs 

*•» 


Pleaao  ani.er  yes  or 


If  you  answer  "yes,"  control  is  passed  back  to  NOW  for  another 
resource  allocation  with  a  different  investment  strategy.  If 
you  answer  "no,"  the  subroutine  enters  the  section  where  it 
constructs  the  graphs. 

As  described  in  Figure  2,  four  types  of  graphs  are  avail¬ 
able  through  subroutine  GRAPH.  Note  that  Graph  Type  4  can 
portray  the  results  of  only  one  resource  allocation  at  a 
time.  The  graph  will  still  represent  only  those  results  even 
if  you  have  saved  the  results  of  applying  resource  allocation 
methodology  to  different  mission  areas  or  in  some  other  manner 
have  constructed  noncomparable  results  in  a  series  of  resource 
allocations.  The  rest  of  the  graphs  compare  the  data  resulting 
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FIGURE  2 

SUMMARY  OF  SUBROUTINE  GRAPH  CAPABILITIES 


Graph  Type  1 

Graph  of  benefit  of  solution  to 
individual  task  versus  total 
solution  costs  summed  over  all 
years. 

Each  point  plotted  is  total  cost  of 
solution  due  to  strategy  k  versus 
benefit  of  that  solution  to  task  i, 
k-  1.2 . j. 


Graph  Type  2 

Total  benefit  versus  total  solution 
cost  for  each  strategy. 

Each  point  plotted  is  the  total 
cost  of  solution  due  to  strategy  k 
versus  total  benefit  due  to 
strategy  k,  k  =  1,  2 . j. 


Graph  Type  3 

Individual  task  benefits  versus  cost 
of  individual  budget  periods. 

Each  point  plotted  is  the  cost  of 
year  i  versus  the  benefit  to  task  n 
for  the  solution  due  to  strategy  k, 
k=  1.2 . j. 


Graph  Type  4 

Cost  of  a  given  strategy  for  each 
budget  period. 


BENEFIT 
TO  TASK  i 


TOTAL  SOLUTION  COST 

BENEFIT 


TOTAL  SOLUTION  COST 


BENEFIT 
TO  TASK  n 


COST  OF  YEAR  i 

COST 


BUDGET  PERIOD 
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from  separate  resource  allocation  runs.  Clearly,  you  must 
make  certain  that  inputs  to  such  graphs  are  comparable. 


Graph  Type  1  depicts  the  total  solution  cost  summed  over 
all  years  versus  the  contribution  of  the  solution  to  a  spe¬ 
cific  task  for  each  strategy.  Thus,  what  is  graphed  is  the 
set  of  points  { (x (k) ,y (i ,k) ,  k=l , . . . , j } ,  where  j  is  the  total 
number  of  solutions  saved  for  graphing;  x(k)  is  the  total  cost 
of  the  solution  corresponding  to  the  kth  strategy  the  user  has 
saved;  and  y(i,k)  is  the  benefit  of  the  kth  solution  to  the 
ith  task.  Each  point  on  this  graph  represents  a  different 
resource  allocation.  You  must  input  task  index  i.  The 
computer/user  interaction  needed  to  generate  this  graph  is: 

lo  yo»  want  «>J  iripKi  cf  lei*'.  »ol«tior  iua««d  *v*r  all  yaart  vs.  contrl 

\ckvtio»  of  solktica  to  ladutdi.*  banafit  aaisu ras’ 

Ky  in  indax  for  Uia  banafit  aaaatra. 

aotvtioa  cost  data  83. 90  78.9 t  ’.O'i  f.0 

aolatie*  kaaafit  data  2219.80  283S  88  1520.00 

You  can  generate  this  graph  for  as  many  tasks  as  you  desire. 
Figure  3  shows  a  sample  of  this  graph  type. 

Graph  Type  2  represents  total  solution  benefits  versus 
total  solution  costs  for  each  strategy.  Thus,  the  plot  con¬ 
sists  of  the  set  of  points  (x(k),  y(ngl,k),  k=l,...,j}.  The 
variables  x(k)  and  j  have  the  same  definitions  as  those  in 
Graph  Type  1.  The  variable  y(ngl,k)  stores  the  sum  of  the 
benefits  of  the  kth  strategy,  i.e., 

ng 

y(ngl,k)  =  Z  y(m,k),  ng  =  number  of  tasks. 
m=l 


Once  again,  each  point  represents  a  different  solution.  The 
computer/user  interaction  to  generate  this  graph  is: 
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Benefit  to  task 


FIGURE  3 

SAMPLE  GRAPH  TYPE  1 
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A  sample  of  this  graph  type  is  given  in  Figure  4. 

Graph  Type  3  depicts  the  solution  contribution  to  task  n 
versus  the  cost  of  an  individual  budget  period  i  for  each 
strategy  or  solution.  The  plot  consists  of  the  set  of 
points  |(yr(i,k),  y(n,k)),  k=l,...,j  [  .  The  variables  j  and 
y(n,k)  have  the  same  definitions  as  those  previously  mentioned 
The  variable  yr(i,k)  is  the  total  cost  of  the  kth  saved 
solution  in  the  ith  budget  period.  Again,  each  point  repre¬ 
sents  a  different  strategy.  The  user/computer  interaction 
necessary  to  generate  this  type  of  graph  is: 

•o  no*  nut  any  graph*  of  coal  of  individual  budget  periods  vi.  individual  task  banafils 

«•* 

Kay  in  badgol  period  daairad. 

Kay  la  lank  baaafil  Indax. 

5 

To  ba  plotted  la  a  a  drank  of  coal  of  yaar  3  vj .  bana/lt  lo  task  5  ■ 

aaolut toa  coal  data  3C.1*  33.5V  32. T* 

ao l all on  baaalll  data  7VV.V1  V.7V  V.VV 

You  can  generate  this  graph  type  for  as  many  budget  periods 
and  tasks  as  you  desire.  An  example  is  given  in  Figure  5. 

Graph  Type  4  depicts  the  cost  of  a  single  strategy  for 
each  budget  period.  The  results  of  each  strategy  are  graphed 
separately  to  avoid  the  possibility  of  an  inconsistent  graph. 
The  computer/user  interaction  necessary  to  generate  this 
graph  is: 

Bo  you  east  graph*  *hc»*ng  c»»%  of  slratay,-  for  aacr  t  loot  p#r,  r 

The  subroutine  automatically  generates  this  graph  for  each 
strategy  as  currently  written.  An  example  of  this  graph 
type  is  given  in  Figure  6. 
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Benefit 


Bentf It  to  task 


FIGURE  5 

SAMPLE  GRAPH  TYPE  3 
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For  each  graph  type,  you  are  asked  if  you  want  any  graphs 
of  that  type.  If  the  answer  is  "yes,"  for  Graph  Types  1,  3, 
and  4,  you  are  asked  to  input  the  appropriate  benefit  measure 
indices  or  budget  period  indices.  Note  that  you  cannot  use 
the  budget  period  and  task  directly;  rather,  you  must  use  the 
appropriate  index.  Thus,  if  you  desire  a  graph  involving 
1990  (the  third  budget  period),  you  must  input  the  index  "3", 
not  1990. 

Since  Graph  Type  2  has  no  alternatives  associated  with 
it,  the  system  will  simply  ask  whether  or  not  you  want  it. 
Answer  "yes"  or  "no";  no  other  inputs  are  necessary 

After  each  graph  is  produced,  a  question  mark  will  flash 
in  the  upper  lefthand  comer  of  the  screen.  You  may  now  make 
a  copy  of  the  graph  on  the  Tektronix  4631  photocopier.  To 
inform  the  subroutine  that  you  are  ready  to  move  on  to  the 
next  graph,  type  "q"  and  hit  the  return  key.  You  should 
clear  the  screen  before  typing  "q"  to  avoid  screen  clutter. 

If  you  do  not,  the  next  question  will  be  printed  over  the 
graph,  which  is  not  automatically  removed  from  the  screen. 

Graph  Types  1,  2,  and  3  pose  a  problem  in  that  each 
point  plotted  on  these  graphs  is  an  output  from  a  different 
strategy,  but  no  information  is  embedded  in  the  graph  to 
tell  you  which  point  is  associated  with  which  strategy.  We 
recommend  the  following  procedure  to  provide  identification. 
Before  displaying  the  graph,  the  subroutine  will  print  the 
data  to  be  graphed.  This  information  occurs  in  two  rows  of 
data.  The  first  entries  in  each  row  correspond  to  the  inputs 
from  strategy  1,  the  second  entries  in  each  row  correspond  to 
the  inputs  from  strategy  2,  and  so  forth.  For  example,  if 
you  have  answered  "yes"  to  the  question,  "Do  you  want  any 
graphs  of  total  solution  costs  summed  over  all  years  vs. 


benefit  of  solutions  to  individual  tasks?",  you  will  be  asked 
to  key  in  a  task  index.  Assume  you  have  keyed  in  index  "5," 
and  that  three  solutions  have  been  saved.  The  following  data 
will  be  displayed: 

solution  cost  data  83.90  70.90  108.60 

solution  benefit  data  700.01  0.70  0.00 

(see  Figure  3).  The  first  two  values  in  each  row,  83.90  and 
700.01,  represent  the  point  (83,90,  700.01)  resulting  from 
strategy  1.  The  second  two  values  represent  the  point  (70.90, 
0.70)  from  strategy  2,  and  so  forth.  We  recommend  that  you 
make  a  copy  of  these  data  when  they  are  flashed  on  the  screen. 
If  you  press  the  "copy"  key  as  soon  as  the  data  are  presented, 
the  copy  can  be  made  before  the  subroutine  is  ready  to  present 
the  graph.  Hopefully,  this  entire  problem  will  be  solved  by 
future  modifications  to  the  subroutine. 

Another  problem,  which  can  easily  be  corrected,  is  that 
once  you  have  answered  the  question,  "Do  you  want  to  generate 
more  data  before  constructing  graphs?"  with  a  "no,"  you  will 
exit  from  subroutine  GRAPH,  and  all  data  stored  in  it  will  be 
lost.  Thus,  no  data  are  saved  after  the  graphs  have  been  made. 

You  may  wonder  why  the  points  in  the  various  graphs  are 
not  connected  with  lines.  The  reason  is  that  the  quantities 
being  graphed  do  not  change  in  a  linear  fashion;  rather, 
values  tend  to  jump  suddenly.  Furthermore,  the  parameter 
changes  that  will  cause  a  change  in  the  optimal  solution  are 
not  predictable  without  extensive  sensitivity  analysis.  Thus, 
"connecting  the  dots"  in  the  usual  linear  fashion  is  mathe¬ 
matically  meaningless. 

The  last  concern  is  that  graphs  can  be  produced  only 
from  Tektronix  CRT  terminals  that  are  attached  to  the 
Multics  computer  system. 


III.  PROGRAMMER'S  GUIDES 


A.  Programmer 1 s  Guide  to  Program  NOW 
1 .  Background 

This  program  acts  as  an  interface  between  the  user,  the 
data  base,  and  the  allocation  and  graphic  subroutines.  The 
user  inputs  the  mission  area,  appropriation,  and  years  under 
consideration  and  their  budget  ceilings.  The  program  then 
retrieves  program  elements  (PE)  numbers  and  alternatives 
from  the  data  base  and  indexes  them  for  input  to  the  allo¬ 
cation  routine.  The  results  are  passed  to  the  output 
subroutine  and  then  to  the  graphics  subroutine.  When  sub¬ 
routine  GRAPH  is  finished,  the  program  run  is  essentially 
finished,  and  the  user  may  stop  or  choose  one  of  the  other 
options  to  generate  a  new  problem.* 

The  main  program  is  written  in  PL/1,  and  some  of  its 
significant  features  are: 

o  The  range  of  a  DO  loop  is  terminated  at  the  first 
"end"  statement,  which  is  equivalent  to  the  FORTRAN 
"continue"  with  the  appropriate  statement  number 
in  front. 

o  The  concatenation  operation  joins  two  or  more 
strings  together  into  one  larger  string. 

o  The  four  subroutines  that  are  written  in  PL/1  are 
all  physically  contained  in  the  main  program.  This 
means  that  a  variable  in  the  main  program  is  known 
by  the  same  name  in  the  subroutines,  as  long  as  it 
is  not  declared  in  that  subroutine.  This  eliminates 
the  need  for  argument  lists  in  the  call  statements 
to  these  subroutines. 


*For  details  on  how  to  solve  problems  with  this  routine,  see 
"User's  Guide  to  Program  NOW,"  Section  II. A. 


o  PL/1  stores  its  array  elements  in  row-major  order; 
that  is,  the  rightmost  subscript  varies  most  rapidly. 
This  differs  from  FORTRAN,  which  uses  column-major 
order.  Here,  the  dimensions  of  any  two-dimensional 
array  in  the  main  program  must  be  reversed  from  th~ 
dimensions  of  the  corresponding  array  in  either  of 
the  FORTRAN  subroutines,  before  the  values  can  be 
passed  correctly  through  the  argument  list. 

The  program  accesses  the  data  base  through  the  built-in 
dsl  subroutines  to  retrieve  the  necessary  data.  Each  dsl 
call  is  usually  followed  by  a  statement  that  calls  the 
com_err_  subroutine  if  the  variable  code  is  not  equal  to 
zero.  This  is  only  the  case  if  something  abnormal  has 
occurred  during  the  dsl  subroutine,  and  com_err_  will  print 
out  a  description  of  the  error  that  caused  the  nonzero 
code. 

A  new  search  rule  must  be  added  to  the  user's  ordinary 
search  rules  so  that  the  system's  graphics  subroutines  can 
be  located  when  called.  The  add_search_rules_  (asr)  command 
accomplishes  this  task  and  may  be  done  automatically  if  the 
command  is  placed  in  the  user's  start-up. ec. 

2 .  Program  Description 


This  program  is  described  sequentially.  Line  numbers 
have  been  added  for  convenient  reference  and  are  keyed  to  the 
computer  code  listed  in  Section  IV. A  of  this  volume. 


■  Program  Description 


Line 

NO. 

1  Procedure  statement  -  entry  point  to  program 

2-9  Declaration  of  all  external  subroutines 

10-16  Declaration  and  definition  of  a  block  for  the  quit 
(interrupt)  condition.  If  the  break  key  is  passed 
while  the  program  is  running,  control  will  be  trans 
ferred  to  this  block,  which  ensures  that  the  data 
base  is  properly  closed  before  returning  to  command 
level 

17-18  Declaration  of  integer  variables  and  arrays 

19  Declaration  of  binary-based  floating  point  data, 
which  corresponds  to  the  FORTRAN  "real"  data 

20  Declaration  of  the  cost  data  as  fixed  decimal  to 
correspond  with  the  numbers  in  the  data  base 

21-29  Declaration  of  all  character  data 

30-35  Initialization  of  some  character  data  to  the 
different  parts  of  a  dsl  subroutine  call's 
selection  expression 

36  Initialization  of  the  variable  path  to  the  path 
name  of  the  proper  data  base 

37  delta  is  set  to  a  small  positive  number 

38  rseed  is  set  to  any  random  seed 

39  Initialization  of  five  different  variables  to  zero 

40-41  Person_id  is  asked  for  and  read  in 

42-43  User  is  asked  to  input  rd  or  sc  for  data  base,  and 

the  response  is  read  into  the  data  base 
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44-48  The  data  base  is  opened.  If  an  error  occurs, 
com_err_  is  called  and  processing  is  halted 

49-50  Scope  is  set  on  the  "protect"  submodel,  and  com_err_ 
is  called  if  an  error  occurred 

51-58  The  first  mission  area  that  the  user  has  access  to 
is  retrieved,  and  the  usual  precautions  are  taken 
in  case  of  an  error 

59  A  mission  area  access  heading  is  printed  out 

64-65  The  user  is  asked  if  he  wants  official  data,  and 

yes(y)  or  no(n)  is  read  into  dc 

66-67  The  user  is  asked  to  input  the  mission  area,  and 
the  response  is  read  into  subma 

68-73  If  the  user  entered  "none"  for  mission  area,  then 
the  data  base  is  closed  and  processing  stopped 

74-75  If  the  user  wants  official  data  then  ma  is  set 

equal  to  "off";  otherwise  it  is  set  to  the  mission 
area 

76-78  The  name  of  the  submodel  that  the  user  will  be  ac¬ 
cessing  to  obtain  PE  numbers  and  cost  data  is 
retrieved,  and  com_err_  is  called  if  an  error  occurs 

79-85  Scope  is  deleted,  the  data  base  is  closed,  and 

com_err_  is  called  if  either  code  does  not  equal 
zero 

86-87  Ask  for  appropriation  and  read  into  appro 

88-89  Ask  for  number  of  years  to  be  considered,  and 

read  into  nper 

90-93  Ask  for  year  and  budget  ceiling  for  each  period, 
and  read  into  nyr (  )  and  b(  ) 

94-104  This  section  opens  the  proper  submodel  and  sets 

scope  on  "char"  and  "relation."  Char  is  the  part 
of  the  data  base  that  contains  PE  numbers  and 
their  different  funding  alternatives.  Relation 
is  a  variable  that  represents  the  part  of  the 
data  base  that  contains  the  appropriate  cost  data 


This  section  is  skipped  if  dec  equals  five.  This 
can  happen  only  if  the  user  selected  option  five 
after  the  first  allocation  was  completed.  If 
this  is  the  case,  then  these  instructions  are 
unnecessary  and  so  can  be  omitted 

105  The  number  of  groups  (PE  numbers)  is  initialized 
to  zero 

106  exp8  is  set  to  a  character  string  that  forms  the 
selection  expression  of  the  data  base  call  that 
will  retrieve  PE  numbers  given  the  mission  area 
and  appropriation 

107  The  first  PE  number  is  retrieved 

108-117  This  block  is  activated  if  the  preceding  retrieval 
resulted  in  an  error.  An  error  message  and  three 
user  options  are  printed  out,  and  control  is  trans 
ferred  as  desired 

118-122  This  loop  retrieves  all  remaining  PE  numbers  and 
places  them  in  penum(  ) 

123  The  number  of  variables  (a  PE  and  an  alternative) 
is  initialized  to  zero 

124  exp7  is  set  to  a  character  string  that  represents 
the  selection  expression  of  a  data  base  call  that 
will  retrieve  the  alternatives  and  cost  data  for 
each  PE 

125  A  heading  is  printed  out  for  any  zero  cost  alter¬ 
natives  that  may  be  found 

126-175  This  loop  retrieves  all  the  alternatives  and  the 
cost  data  for  each  for  a  given  PE.  If  any  alter¬ 
native  has  cost  equal  to  zero  for  all  the  years 
under  consideration,  then  it  will  not  be  indexed 
as  a  variable.  If  all  the  alternatives  under  a 
PE  have  zero  cost,  then  that  PE  will  be  eliminated 
and  ngr  reduced  by  one 

127  If  i  equals  the  reduced  number  of  groups,  then  go 

to  the  next  i 
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130 


The  ifc^  PE  number  is  obtained  from  penum(  ) 

131  The  first  alternative  and  its  associated  cost 

data  are  retrieved 

136  Subroutine  DCOST  is  called 

137-141  The  current  alternative  is  checked  for  zero  cost. 

If  yes,  then  the  PE  and  alternative  are  printed 
out  and  flagl  and  jj  are  set  to  1.  Flagl  =  1 
signifies  that  the  first  alternative  under  this  PE 
has  zero  cost.  jj  is  changed  from  2  to  1  because 
k,  which  indexes  the  remaining  alternatives  under 
this  PE,  is  started  at  jj  and  in  this  case  will 
be  the  first,  not  the  second,  variable 

142-148  If  the  first  alternative  was  a  valid  one,  however, 
then  this  section  is  processed  instead  of  the 
previous  one 

143  The  number  of  variables  is  incremented 

144  Subroutine  COST  is  called  to  store  the  cost  data  of 
the  current  variable 

145-147  The  variable  is  indexed  into  the  group  number  and 
the  alternative  number  under  that  group  and  the 
funding  level  is  stored  in  the  progalt  array 

149-165  This  loop  retrieves  the  remaining  alternatives 

and  their  cost  data  under  the  current  PE.  It  checks 
for  zero  cost  and  indexes  in  the  same  manner  as  that 
for  the  first  alternative 

166-174  This  section  is  processed  only  if  flagl  =  1  and 
flag2  =  0,  which  can  happen  only  if  no  nonzero 
cost  alternatives  occurred  under  the  current  PE. 

In  this  case,  the  penum  array  is  adjusted  to 
eliminate  that  PE  number,  the  number  of  groups 
is  reduced  by  one,  and  i  is  decremented  so  that  a 
number  will  not  be  skipped  on  the  next  pass  through 
the  loop 

176-178  The  allocate,  output,  and  graph  subroutines  are 

called  in  order.  Allocate  and  graph  are  referenced 
by  <f ilename>$<program  name>,  since  they  are  lo¬ 
cated  in  a  storage  region  outside  of  the  main  pro¬ 
gram 
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179-182  The  user  options  are  printed  and  the  response  read 
into  dec 

183  If  the  user  asks  for  a  different  appropriation,  then 

control  is  transferred  to  statement  12 

184-193  This  section  is  for  a  different  data  base  or 

different  mission  area  options.  Scope  is  deleted, 
the  data  base  is  closed,  and  comm_err__  is  called 
in  case  of  error.  Then  control  is  transferred  to 
the  appropriate  place 

194-204  This  section  is  for  the  different  budget  ceilings 
option.  The  number  of  years  with  new  budgets  is 
asked  for  and  read  into  nchange.  Then  each  year 
and  its  new  budget  level  are  read  in  and  control 
transferred  as  appropriate 

205-211  This  section  is  for  the  option  to  choose  different 
years  of  cost  data.  All  budget  ceilings  are  zeroed 
out,  and  control  is  transferred  back  to  where  the 
years  and  budget  ceilings  are  input 

212-215  This  section  can  be  reached  only  if  the  user  elects 
to  stop.  Scope  is  deleted,  the  data  base  is  closed, 
and  processing  is  halted 
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Description  of  Subroutines  DCOST  and  COST 


DCOST: 


COST: 


output : 
2-8 
9-11 
12 

13-17 

18 

19 

20- 50 

21- 23 
24-25 

26-45 


This  subroutine  checks  all  alternatives  for  zero 
funding.  It  totals  the  cost  of  the  current  alter¬ 
native  over  the  years  under  consideration  and 
returns  that  value  in  asum.  When  dcost  is  finished 
processing,  asum  is  immediately  checked  for  a  zero 
value . 

Once  an  alternative  has  been  determined  to  be  a 
legitimate  variable,  subroutine  cost  is  called  to 
store  its  cost  data.  The  main  program  uses  the 
array  cst,  with  cst(i,j)  the  cost  of  variable  j  in 
budget  period  i.  Note  that  these  dimensions  are 
reversed  in  the  corresponding  c  array  in  the  two 
fortran  subroutines. 


Declarations  and  initializations 

Print  instructions  and  read  in  a  dummy  character 

Set  the  entire  sum  array  equal  to  zero 

Since  six  alternatives  will  be  printed  per  page, 
this  block  determines  how  many  pages  will  be 
required  and  how  many  alternatives  will  be  left 
for  the  last  page. 

Skip  two  lines  of  output 

Concatenate  a  data  base  variable  to  represent  the 
selection  expression  necessary  to  retrieve  the  cost 
data  for  each  variable 

This  loop  prints  a  page  of  output  each  time  through 
Print  page  heading 

Set  upper  limit  on  inner  loop  to  6,  unless  this  is 
the  last  page  to  be  printed 

This  loop  prints  an  alternative  and  its  associated 
data  each  time  through 


27-29  Determine  the  PE  number  and  funding  alternative  for 
the  current  variable 

30-35  Retrieve  the  PE  title  for  the  current  variable,  call 
com_err_,  and  exit  the  loop  if  an  error  occurs 

36-37  Retrieve  the  cost  data  for  the  current  variable,  and 
exit  the  loop  if  an  error  occurs 

38  Call  subroutine  sumcost  to  maintain  a  running  total 

of  the  cost  of  the  solution  for  each  budget  period 

39-45  Print  out  the  current  variable  and  its  cost  and  benefit 
data,  and  repeat  loop  until  ii  >  indexl 

46  If  all  output  is  finished,  print  the  cost  total  for 

each  budget  period 

47-48  Print  another  heading,  and  skip  two  lines 

49  Read  in  a  dummy  character 

50  End  the  page-printing  loop 
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3.  Definition  of  Variables 


nvar : 

ngr : 

pe : 

penum 
(  )  : 

appro : 

pealt : 

progalt 
(r.)  : 

ma  : 

subma : 

nper : 

nyr 
(n)  : 

ny : 

budget : 
b  (n) 

yrl -yr7 : 
cst 

(i# j)  : 

sum(n)  : 


The  number  of  variables.  A  variable  is  a  specific 
funding  alternative  with  nonzero  cost  under  a 
given  PE  number 

The  number  of  groups  or  PEs  under  a  given  mission 
area  and  appropriation  with  at  least  one  nonzero 
funding  alternative 

PE  number  under  consideration 


Contains  all  legitimate  (nonzero  funding)  PE  numbers 
Appropriation 

Funding  alternative  under  consideration 

Funding  alternative  of  variable  n 

Equals  "off"  for  official  data;  otherwise  equals 
mission  area 

Mission  areas,  000  to  900;  used  to  retrieve  PE 
numbers 

Number  of  budget  periods  that  will  be  considered  for 
the  problem 

a,  y. 

n  year,  two  digits,  79-85 
Year  index  number,  =  nyr(y)  -  78 
Budget  ceiling  for  a  given  year 
Budget  ceiling  for  year  n 
Cost  data  for  a  given  variable 


Cost  of  variable  j  in  budget  period  i 
Total  cost  of  solution  in  period  n 
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delta:  Small  positive  number,  to  check  for  zero  cost 

alternatives 

asum:  The  total  cost  of  an  alternative,  summed  over  all 

periods  under  consideration 

nchange:  User  option,  number  of  years  with  a  new  budget 
ceiling 

init:  Passes  to  subroutine  GRAPH  the  number  of  times  that 

it  has  been  called  minus  1 

dummy:  A  1-character  dummy  variable  used  to  temporarily 

halt  the  output  so  that  the  user  may  reset  page 
if  a  CRT  is  being  used 

expl 

exp8:  Character  strings  that  contain  parts  of  the  various 

data  base  selection  expressions 

sub¬ 
model:  The  submodel  (subset)  of  the  data  base  that  will  be 

accessed 

data 

base  The  path  name  of  the  proper  submodel 

dbi , 

dbil :  Data  base  index  numbers,  returned  from  a  dsl  $open 

call 

code:  Returned  by  all  dsl  subroutines;  code  equals  zero 

if  the  data  base  call  was  performed  successfully; 
otherwise  it  equals  a  particular  number,  depending 
on  the  exact  error  that  disabled  the  subroutine 

db:  Data  base,  rd  or  sc  as  user  desires 

rela¬ 
tion:  The  specific  area  in  the  data  base  that  contains 

the  appropriate  cost  data 

ilev 

(n) :  Index  number  of  variable  n  under  its  PE  number 
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igr (n) : 
js (n) : 
jls 

zw ( i , j )  : 
ng : 

xl() ,yl 0 
y2()  : 


Index  number  of  the  PE  to  which  variable  n  belongs 

Index  number  of  n^^  solution  variable 

Number  of  variables  in  the  solution 

Benefit  to  task  i  from  variable  j 

Number  of  goals  (tasks) 

f 

Arrays  that  preserve  the  values  of  three  arrays  of 
subroutine  GRAPH  in  case  it  is  called  more  than  once 
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Programmer's  Guide  to  Subroutine  GRAPH 


Program  Description 


This  section  describes  in  detail  the  workings  of  sub¬ 
routine  GRAPH.  You*  should  read  it  with  a  subroutine  listing 
in  hand  (see  Section  IV. B) .  An  alphabetical  listing  of 
variable  definitions  is  given  in  Section  III.B. 

Before  starting  into  subroutine  GRAPH,  we  should  discuss 
the  parameter  j,  which  is  passed  to  GRAPH  in  the  subroutine 
call  statement.  The  parameter  represents  the  number  of 
sets  of  resource  allocation  output  data  you  have  saved  to  be 
graphed.  You  must  set  j  equal  to  zero  in  the  calling  program 
before  calling  GRAPH. 

The  variables  c,  uper,  js,  ngr,  nvar,  ng,  nyr,  zw,  jl, 
x,  y,  and  yr  are  listed  as  subroutine  arguments  because  the 
calling  program  is  written  in  PL/1.  A  PL/1  program  may  not 
share  variables  with  a  FORTRAN  subroutine. 

The  first  DO  loop,  DO  2 ,  and  the  statement  preceding  it 

x(j+l)=0.0, 

initialize  x(j+l)  and  yr(L,j+l),  L=1 , . . . ,nper .  The  DO  5  loop 
computes  the  total  solution  cost  x(j+l)  and  the  cost  per- 
budget  period  of  the  solution  yr(L,j+l) 

jl  nper 

x(j+l)=  E  I  c(js(i),L) 
i=l  L=1 


yr(L,j+l)=  E  c(js(i),L)  ;  L=l,...,n 
i=l 

where  L  indexes  budget  periods  and  i  indexes  the  selected 
program  alternatives.  The  total  solution  cost  is  printed 
out  at  this  time. 


You  in  this  section  refers  to  you,  the  programmer.  However 
at  times  you  will  be  taking  on  the  role  of  user  as  well. 


The  next  DO  loop,  DO  10,  computes  the  contributions  of 
the  solution  to  the  goals  with  respect  to  which  benefits  are 
measured  (also  called  tasks),  y(m,j+l),  for  each  task  m. 

Thus 

jl 

y(m,j+l)  =  l  zw(js(i),m)  ,  m=l,...,ng. 
i=l 

The  total  benefits  for  these  tasks  are  also  printed  out. 

At  this  point,  you  have  the  total  solution  cost  and  the 
total  solution  benefit  as  follows: 


fh.  total  cost  of  tha  solution  is 


10c  .<■? 


contribution 

ic 

toil, 

1  • 

: :  ki* 

contribution 

to 

task 

2  • 

31  K 

contribution 

to 

task 

3  ■ 

3i  .»e 

contribution 

to 

task 

4  . 

contribution 

to 

task 

5  • 

contribution 

to 

task 

6  - 

•  ■ec 

contribution 

tc 

tasn 

■>  . 

a.se 

contribution 

♦  5 

task 

8  ■ 

1  85 

Do  you  wont  the  owlput  froo  U  .s  strategy  «lvea  f  z* 
\cor  no. 

Ho  you  I  to  go-.ersta  date  tt'  .*r* 

so 

Do  you  M«Pt  tnu  erephs  of  tela  • 

Ncksi  iOf»  of  so  <  ut i or  1c  ind.xidua 


it.cn 
t »r.ef  .t 


5*  .* 


« -f  t  .  ny  j*  v  ►  •.'* 

over  all  years  v/s  co«tri 


Ifoy  m  index  for  the  benefit  *«v.>re. 
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You  are  then  asked  whether  you  want  to  save  the  data  associ¬ 
ated  with  this  solution  for  incorporation  into  graphs.  If 
you  answer  "yes,"  j  is  incremented  by  1, 


Since  the  value  j+1  was  used  in  the  DO  5  and  DO  10  loops, 
incrementing  j  has  the  effect  of  saving  the  results  of  these 
loops.  Also  at  this  time,  the  sum  of  the  benefits  of  the 
solution,  y(ngl,j),  is  computed  in  the  DO  15  loop, 

ng 

y  (ngl ,  j  )  =  I  y  (m,  j)  . 
m=l 

You  are  then  asked  if  you  want  to  generate  more  data 
using  additional  investment  strategies  before  constructing 
graphs.  This  questi'  is  also  asked  if  you  answered  "no"  to 
the  preceding  question.  (However,  if  you  did  answer  "no,"  j 
will  not  be  incremented,  and  the  next  time  GRAPH  is  called, 
the  current  stored  values  will  be  lost.)  If  you  want  to 
generate  more  data,  control  is  passed  back  to  the  calling 
program.  If  you  do  not,  you  are  taken  to  the  portion  of 
the  subroutine  that  generates  the  graphical  output.  We 
will  proceed  under  the  assumption  that  you  answered  "no." 

The  first  graph  type  (see  Figure  3  for  sample)*  that  can 
be  generated  is  the  contribution  of  the  solution  to  individual 
tasks  y(i,k),  m+l,...,ng  versus  total  solution  costs  summed 
over  all  years,  x(k),  for  each  solution  k,  k=l,...,j.  Thus, 
a  graph  consists  of  a  set  of  points  { (x (k) ,y (i ,k) ) ,  k=l,...,j). 
You  are  asked  if  you  want  any  graphs  of  this  type.  If  you 
answer  "yes,"  you  are  then  asked  to  key  in  the  index  i  for 
your  desired  task.  The  index  is  an  integer  from  the  set 
{l,2,...,ng}  referencing  one  of  the  tasks.  If  you  answer 
"no,"  control  jumps  to  the  "101  continue"  statement  for 
entry  into  next  graph  type.  We  will  proceed  under  the 
assumptic  that  you  answered  "yes." 

*For  a  summary  of  all  graph  types  offered,  see  Figure  2. 
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Once  you  have  selected  the  benefit  measure  index  i,  the  DO 
27  loop  stores  the  value  of  y(i,k)  in  the  single  subscripted 
variable  z(k),  k=l,...,j.  This  is  necessary,  since  the 
"xyplot"  statements  used  to  construct  the  graph  will  not 
accept  a  double  subscripted  variable. 

The  total  solution  cost  x(L)  is  written  out  for  each 
solution  L,  L=l,...,k,  and  the  contribution  of  the  solution 
to  task  i,y(i,L)  is  written  out  for  each  solution  L,  L=l, 

.  ..,j.  You  should  make  a  copy  of  this  information  when  it 
appears  on  the  screen,  since  you  will  have  no  other  way  of 
knowing  which  point  on  the  graph  is  associated  with  which 
strategy. 

The  encode  and  associated  statements  that  now  occur  are 
used  to  concentrate  the  task  index  i  to  the  rest  of  the 
graph's  title,  stored  in  zz,  and  the  rest  of  the  y-axis 
title,  stored  in  ben.  If  you  are  unfamiliar  with  encode 
statements,  you  should  consult  Mulcxcs  system  documentation 
before  tampering  with  encode  statements,  variables  used  in 
encode  statements,  or  format  statements  associated  with 
encode  statements.  The  encode  statement  is  discussed  on 
pages  5  through  12  of  the  Multias  FORTRAN  Guide. 

The  "call  xyplot"  statements  that  now  occur  call  system 
subroutines  that  construct  and  display  the  graph.  A  complete 
discussion  of  the  xyplot  statements  is  contained  in  the  do¬ 
cument  XYPLOT,  which  was  prepared  by,  and  is  available  from, 
Mr.  Robert  G.  Finney  of  the  Air  Force  Data  Services  Center. 

Once  the  graph  has  been  displayed,  a  question  mark  will 
appear  in  the  upper  lefthand  corner  of  the  screen.  This 
indicates  that  you  may  now  make  a  copy  of  the  graph  on  the 
Tektronix  4631  photocopier.  Once  you  have  made  a  copy  of 
the  displayed  graph,  clear  the  screen  to  avoid  the  clutter 


that  arises  from  overprinting  on  the  graph  (the  graph  will 
not  be  removed  automatically) .  Then  inform  the  system  that 
you  are  ready  to  move  on  to  another  graph  by  typing  "q". 

Upon  receipt  of  the  "q"  signal,  the  subroutine  returns  to 
the  question,  "Do  you  want  any  graphs  of  this  type?"  If 
you  do,  the  preceding  sequence  is  repeated.  If  you  do  not, 
the  subroutine  goes  to  the  "101  continue"  statement  to  initiate 
proceedings  on  the  next  type  of  graph. 

The  next  statement  after  the  "101  continue"  statement 
asks  whether  you  would  like  a  graph  of  total  benefit  versus 
total  cost  for  each  alternative  (see  Figure  4  for  sample) .  If 
you  do  not,  control  is  shifted  to  the  "206  continue"  state¬ 
ment  before  the  next  set  of  graphs.  If  you  do,  the  subrou¬ 
tine  proceeds  to  construct  this  graph.  The  DO  110  loop 
stores  the  sum  of  the  benefits  of  the  kth  strategy  y(ngl,k) 
in  the  single  subscripted  variable  z(k)  because  "xyplot" 
statements  will  not  accept  double  subscripted  variables  as 
inputs . 

Next  the  system  displays  the  x  and  y  coordinates  of  the 
points  to  be  graphed,  (x(L),L=l,j)  and  (y(ngi,L),  L=l,...,j). 

As  we  have  mentioned  previously,  you  should  make  a  copy  of 
this  information  on  the  Tektronix  4631  copier.  The  "call 
xyplot"  statements  create  and  display  the  graph  of  the  set 
of  points  { (x (L) ,y (ngl ,L) ,  L=l,...,j}. 

The  next  graph  type  shows  individual  task  benefits  for 
each  strategy  versus  individual  budget  periods  (see  Figure  5 
for  sample).  If  you  want  a  graph  of  this  type,  key  in  the 
budget  period  you  desire  and  the  benefit  measure  index.  The 
DO  214  loop  stores  the  double  subscripted  variables  y(n,k) 
and  yr(i,k)  in  the  single  subscripted  variables  z(k)  and 
v(k),  respectively.  The  arrays  of  numbers  to  be  graphed 
{yr (i,L) ,L=1, j}  and  {y(n,L),  L=l,j)  are  then  printed  out. 
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The  encode  statements  set  up  the  title  and  x-axis  and  y-axis 
labels.  The  xyplot  statements  construct  and  display  the  graph. 

After  you  have  viewed  the  graph  and  signaled  the  system 
to  continue  with  the  program,  control  is  returned  to  the  "201 
continue”  statement.  You  are  then  asked  if  you  want  any  more 
graphs  of  this  type.  If  so,  the  sequence  repeated.  If  not, 
control  is  transferred  to  the  "301  continue"  statement  for  the 
final  set  of  graphs. 

The  last  graph  type  shows  the  cost  of  an  individual  stra¬ 
tegy,  or  solution,  for  each  budget  period  (see  Figure  6  for 
sample).  Thus,  the  set  of  points  graphed  is  { (yr (i,n) ,nyr  (i) , 
i=l , . . . ,nper } .  This  graph  is  automatically  produced  for  each 
n,  n=l,...,j  if  you  want  any  graphs  of  this  type. 

When  the  "401  continue"  statement  is  executed,  the  graph¬ 
ing  is  completed.  If  you  set  j  equal  to  zero,  you  will  rein¬ 
itialize  subroutine  GRAPH.  Data  currently  stored  in  sub¬ 
scripted  variables  will  be  overwritten  the  next  time  sub- 
toutine  GRAPH  is  called  by  program  NOW. 

2 .  Definitions  of  Variables  Used  in  Subroutine  GRAPH 

ben  Character-string  variable  used  in  constructing 

the  legend  for  the  y-axis  on  several  of  the 
graphs 

c(js(i),l)  Cost  of  the  js(i)th  program  alternative 
during  the  1th  budget  period 

cost  Character-string  variable  used  in  constructing 

the  legend  for  the  x-axis  on  one  of  the  graphs 

iz  Used  in  an  xyplot$build  statement  to  indicate 

the  type  of  symbol  to  be  used  to  designate 
plotted  points 
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j 


jl 

ng 

ngl 

nper 

nyr (i) 
title 

tie 

tpe 

tse 

v(k) 

x(  j) 


Denotes  the  number  of  different  solutions  to 
the  resource  allocation  problem  that  have  been 
stored  in  subroutine  GRAPH;  each  time  the 
user  answers  the  question  "Do  you  want  the 
output  from  this  strategy  saved  for  graphs?" 
with  a  "yes,"  j  is  incremented  by  1,  and  the 
solution  is  saved 

Number  of  selected  PE  alternatives 

Number  of  goals  or  tasks  toward  which  resources 
are  allocated  by  the  resource  allocation  al¬ 
gorithm 

Used  in  several  places  as  a  temporary  storage 
location  for  the  value  ng+1 

Number  of  budget  periods  over  which  program 
costs  have  been  computed;  budget  periods  would 
typically  be  in  fiscal  years 

The  ith  budget  period;  for  example,  if  the 
second  budget  period  is  1990,  the  nyr (2) =1990 

Character  variable  used  to  store  the  title  of 
each  graph;  previous  content  stored  in  title 
must  be  deleted  before  new  content  is  inserted 

Character  variable  used  in  building  up  the 
legend  for  the  y~axis  of  one  of  the  graphs 

Character  variable  used  in  building  up  the 
legend  for  the  y-axis  of  one  of  the  graphs 

(same  as  above) 

Used  to  store  yr(i,k)  for  each  k;  necessary 
because  arguments  called  by  xyplot$build  must 
be  variable  with  a  single  subscript,  so  a 
graph  using  the  values  stored  in  yr(i,k) 
cannot  be  built  using  yr(i,k)  as  an  argument 

Stores  the  total  cost  of  the  solution  corres¬ 
ponding  to  the  jth  strategy  that  the  user 
saves  to  be  graphed 
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xlabel 


y(rn,  j) 

y (ngl, j) 

ylabel 
yr (1, j) 

2(1) 

zw(  js  (i)  ,m) 

zz 


Character  variable  that  is  used  in  storing  the 
legend  for  the  x-axis  of  each  of  the  graphs 

Stores  the  benefit  of  the  jth  strategy  or 
solution  to  the  mth  task 


Stores  the  sum  of  the  benefits  of  the  jth 
strategy 


Character  variable  that  is  used  in  storing  the 
legend  for  the  y-axis  of  each  of  the  graphs 

Stores  the  total  cost  of  the  jth  strategy  or 
solution  in  the  1th  budget  period 


Used  to  store  the  value  of  y(i,l)  for  each  1; 
necessary  because  arguments  called  by  xyplot$ 
build  must  be  variables  with  a  single  subscript, 
so  a  graph  using  the  values  of  y(i,l)  cannot  be 
built  using  y(i,l)  as  an  argument 

Stores  the  value  of  the  contribution  of  the 
js(i)th  program  alternative  to  the  mth  benefit 
measure 

Character  variable  used  to  store  the  title  of 
each  of  the  graphs 
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IV.  COMPUTER  CODES 


A.  Program  NOW 


pr  now.pl  I 


now.pl  I  11/05/79  1224.)  est  Mon 


now»  proc  optl ons (ma 1 n ) 1 

del  (ramSallocate.gphSgraph)  entry  optlons(variable) 1 
del  dsl_Sopen  entry  options ( variable ) I 
del  dsl_Sclose  entry  options! variable ) I 
del  dsl_sdl_scope_all  entry  options(variable) 1 
del  dsl_Sdl_scope  entry  op t i ons ( var iabl e ) I 
del  dsl_sse t_scope  entry  optionst variable) i 
del  dsl_$re tr ieve  entry  op ti ons ( var iabl e ) 1 
del  com_err_  entry  op tlons ( var iabl e ) I 
dc  1  quit  condition! 
on  quit 
begin! 

call  dsl_$close (dbi I .code ) I 
call  dsl_Sclose (dbi .code ) I 
stop! 
end  i 

del (dbi ,dbl I ,dec,code,llev(350), lgr(3i>0),nyr ( 10) ,sum( 7),ng, 
pern, ny , J1 , Js( 80) ,nvar ,ngr ,nper , f lag  I , f lag2 )  fixed  binary! 

del (y I ( 1 0,25) ,x I ( 1 0) ,est ( I  0, 350) ,b< 10) .rseed .del ta .budge t ,zw( 4,500  >  >  binary  f  loa  • 
S3  dcKyrl  ,  yr  2,  yr  3,  yr4 ,  yr  5,  yr6,yr  7,  asum)  fixed  dec ima 1 ( 8 , 0) ! 
dc 1 (peal t .progal t ( 350) ,db)  char(2),dc  chartl), 

(ma, answer)  char(3), 

appro  char(4),  (pe.penumtdO)  )  char<6), 
dp  char(9),  (submodel ,expl )  char(IO), 
relation  char(B),  subma  char(3), 
exp2  chart  19),  exp 5  char (20) .path  char(25), 

(name,person_ld)  chart  15),  acct  char(32), 

database  char(35),  exp3  char ( 46) ,exp8  chart)03), 

exp4  char(l30),  exp7  char(l48)i 

exp  I -“-range  (p  "I 

exp2  =  ")  (c  char)  -select  41 1 

exp3=“p.pe  -where  (t(c.ma_x00  =  .V.)  &  (c.pe  =  p.pe)"! 
exp5=“)  4  (p. appro  *  .V.))"! 

exp4=")  -select  p.dp  p.yrl_dol  p.yr2_dol  p.yr3_dol  p.yr4_dol  p.yr5_dol  p.yro_dol 

"p .yr  7_dol-where  ((p.pe-.V.)  4  (p. appro  =  .V.))'1! 

pa  tn=4’>udd>dOI  S>rdis_l  ib>SD_D8>"  I 

delta=. 000001 ! 

rseed=74d52399.0! 

lnl t ,dbl ,dbi I .dec ,ngr I =0! 

HO  put  skip  llst("tnter  your  Multlcs  person_ld" ) I 
1  get  1  is t ( person_ld ) ! 

14«  put  skip  llstt'hthat  database?  rd  or  sc?")l 
get  listtdb)! 

15*  call  dsl_topen( “»udd>KDIS>rdis_l ib>rtD_DB>protec  t  .dsro41  ,dbl I , I .code  > I 
if (code**0)  then 

do!  call  com_err_( code, "opening  protect4’)! 

stop! 

end  l 
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ca  11  dsl_Sset_scope<dbi  I  ,"protec  t",  t ,  0,30, code  >  * 

_ Ificode^O)  then  call  com_err_(code, “se tt Ing  scope  on  protect'1)! 

call  dsl_Sretrieve(dbl I ,"-range(p  protect)-select  p.ma  p. permission  -wherefp. 
person_id,roa, perm, code) « 
if(code''=0)  then 

dot  call  com_err_(code, "retrieving  «ia'sJI)i 
call  ds l_$c lose (dOl 1 .code) I 

lf<code'“=0)  then  call  com_err_(code, "closing  database")! 

stop! 

end  l 

put  skip  llst(“You  have  access  to  the  following  mission  areas*")!-- 
60  do  while ( code=0 ) l 
puc  skip  iist(ma)* 

call  dsi_Sretrleve(doi I , "-another", per s on_i d,ma , perm, code ) ! 
end! 

put  skip! 2)  llst("off  data?")! 
get  list(dc)l 

II »  put  skip  list(">!hlch  mission  area?  If  none,  type  'none' ) I 
get  list! subma ) i 
i f ( subma="non“ )  then 

do!  call  dsl_Sdl_scope_all <dbi I .code ) ! 

_ _ call  dsl_$cl  ose  ( dblT*,  code )  I 

If (code"“-0)then  call  com_err_<code, "clos ing  database")! 

stop! 

end  i 

lf(dc»"y")  then  ma*"off,,l 
else  ma»submai 

call  dsl_Sretrieve(dbi I ,“-range(p  protect)-select  p.submodel-where((p.ma=.V 
ma,person_ld, submodel, code) i 

If (code'“=I0)  then  call  com_err_< code, "Choosing  ma's")! 

12*  call  dsl_Sdl_scope_all (dbi I .code ) l 
JjCuf <code'‘=0)  then  call  com_err_(code ,“delet Ing  scope  on  protect")! 
call  dsl_Sclose(dbi I .code) i 
If (code~=0)  then 

do!  call  com_err_(code, "closing  protect")! 

Stop! 
end  i 

put  skip  list("Hhat  appropriation?")! 
get  list(appro)! 

1 /«  put  skip  list("How  many  years  of  cost  would  you  like  to  consider?")! 
get  list(nper)! 
do  1=1  to  npert 

put  skip  listC'Enter  year,  budget")! 

get  list (nyr ( 1 ) ,b( 1 ) ) I 

end! 

lfldec^o)  then 

do!  da  taoase=pa  th 1  submodel ( 

call  dsl_$open(database,dbi, I .code) I 

if (code~-»0)  then 

do»  call  com_err_(code, "opening  database")! 
stop! 

ioo  end! 
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relatior>=db  :;**rp_“  I  iJia  J 

call  ds  l_$se  t_scope(dbi  ."char1* ,  1 ,0,  relation,  1 ,0,code  ) 1 
If <code“«0)  then  call  com_err_tcode, "setting  scope  on  database")! 
end  I 
ngr=Oi 

exp8=exp 1  i  I r  el  at  Ion  1  Jexp2  !exp3 exp5t 

ca  11  dsl_Sretr level dbl ,exp8,subma .appro, pe, code) » 

If  lcode“=0)  then 

do»  call  com_err_t code ,“no  pe")! 

_ gut  skip  edltl“No  pe  was  found  for  mission  area", ma , “  with  approprlat Ion", appro 

“Indifferent  mission  area  and  appropr lation" ,*‘2=di f f erent  aQpropr latlon“,“3=sto 

col 1 1 ) ,a,col 1 1  > ,a ) « 

get  list(dec)! 

lf(dec=l)  then  go  to  111 

lfldec=2)  then  go  to  12i 

else  go  to  18i 

end! 

do  whi 1 e ( code-0 ) I 
ngr=ngr*l 1 
iao  penum  (ngr  )=pe  I 

call  ds l_$r e  tr 1  eve  1 dbl .“—another", subma , appr o, pe , code ) I 
end  i 
nvar=0i 

exp7=expl  I  Irelatlon I Iexp4i 

put  skip  listCThe  following  pe's  and  alternatives  have  zero  fundirr;  for  the  spec 
do  1  =  1  to  ngr! 
lfll-»ngrl)  then  go  to  16i 
JJ=2! 

flag  I  ,f lag2=0! 
pe=penumli ) l 

call  dsl.Sretr level dbi ,exp7,pe, appr o.peal t,yr I ,yr2,yr3,yr4,yr5,yr6,yr7,code ) i 
If <code'*-“0)  then 

do!  call  com_err_(code,"retr levlng  cost  data")! 
go  to  131 
end  l 

call  dcosti 
If lasum<=delta)  tnen 
doi  put  skip  1 1st  1 pe ,peai t ) ! 

J>=l  » 

HO  flag  1  =  11 
■“  end! 
el  se 

do!  nvar*nvar-*  1 1 
call  cost! 
iarlnvar >*1 ! 
ilevlnvar )=l ! 
progal t Invar )*peal tl 
end! 

do  k= JJ  by  I l 

_ S_all  dsl_Sretrleve(dbl,“-anotherJ,,pe,appro,peal t,yr I ,yr2,yr3,yr4,yr5,yr6.yr  /, 

Tft  code"*  =0)  then  go  to  112! 
call  dcosti 
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lf(dec=5)  then 

doi  do  1  =  1  to  nperJ 
nyr ( 1 )=0S 
b( i )=0.0i 
end! 

_ go  to  1 / i 

'  end  I 

18i  call  dsl_$dl_scope_all (dDl , code ) I 
call  dsl_Sclose (dbl ,code ) I 

Iftcode^O)  then  call  com_err_<code,“closing  database'1) » 
s  top  I 

dcosti  proci 
asum=O.Ol 

do  11*1  to  nperl 
ny=nyr < ID -78i 
lf(ny=l)  then  asum=asum+yr 1 1 
else  lf(ny=2)  then  asum*asum*yr2 I 
else  lf(ny*3)  then  asum*asum+yr3 I 
else  lf(ny=4)  then  asum*asum-»yr 4 i 
else  if(ny=5J  then  asum=asum*yr5l 
else  lf(ny=6)  then  asum=asum+yr6l 
else  asutn*asum+yr /l 
end  I 

end  dcosti 

cost*  proci 

do  11=)  to  nperl 
ny=nyr< 11 )-7bi 

lf(ny=l>  then  cst( 11 ,nvar )*yr 1 1 
else  if(ny=2)  then  cst< ii,nvar )=yr2l 
else  lf(ny=3>  then  cst< 11 ,nvar )*yr3l 
else  lf(ny=4>  then  cst( li,nvar )=yr4i 
else  lf(ny*5)  then  cst( il,nvar >=yr5l 
else  lf(ny*6)  then  cst< il,nvar )=yr6» 
else  cst< 11 ,nvar )=yr /I 
end  I 

end  cost! 
output!  proci 

del  exp3  char(10),  exp 4  char(l53),  title  charl2o>, 
rank  char(4),  comment  char(30),  exp7  charCI7l>, 
alt  char(2),  dummy  char(l),exp6  char<IO)t 
expo="-range  (d  " l 
exp3=“-range  (p  *  I 

exp4*")-select  p.yrl_dol  p.yr2_dol  p.yr3_dol  p.yr4_dol  p.yr5_dol 
"p .commentl-where  (((p.pe  *  .V.)  &  (p. appro  *  .V.))  &  (p.dp  *  .V 
put  skip  edlt("l .Type  In  any  character,  reset  page,  and  carriage 
"After  each  page  has  finished  printing,  repeat  step  I ."> (a, col( I 
get  1 1st (du.nny )  t 
sum*Ol 

index*<  J 1  —  I )/6*l  I 


p.yr6_dol  p.yi 
.))"! 
return.", 

) ,  a  )  I 
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1  f (asum<=del ta )  then 
do;  k=k- 1  * 

put  skip  1  is t ( pe ,peal t ) i 
ends 
else 

dos  nvar=nvar+li 
igr (nvar )=i I 

160 _ i_lev(nvar  )=k; 

progal t (nvar )-peal 1 1 
call  cost! 
flag2=l I 
end; 
end* 

1I2«  if(flagl=l  4  flag2=0)  then 
doi 

do  J=i  to  ngr-1 I 
penumi J)=penum( J+l ) I 

_  _  end« 

ngrl*ngrl 
ngr=ngr- 1 1 
i-l-l  l 
end  < 

13«end; 

16«  call  ramSallocate(cst,nper,ngr,nvar ,i lev, igr, b,r seed, nyr, sum, zw, dec , Js.ng, Jl 
call  output; 

call  gph$ graph ( ini t ,cst ,nper , Js.ngr ,nvar ,ng,nyr ,zw, jl ,xl ,yl ) ; 

put  skip  edit("Select  one  of  the  following!", "Indifferent  da tabase" ,"2=di ff erent 
ii£J|t3fdi  fferent  appropriation", "4=di fferent  budgets  for  years  currently  considered", 
“5=different  years  of  cost  da  ta" ,  J,6=s top" ) ( a , col ( I ) , a , col ( I ),a,col( I ) , a , col (  I  ) , a , 
get  list(dec); 
if<dec=3)  then  go  to  12l 
if(dec=l  !  dec=2)then 

do;  call  dsl_Sdl_scope_a 11 (dbi .code ) l 
call  dsl_$close (dbi .code ) ; 
if<code“*0)  then 

do;  call  com_err_<code, "closing  database"); 
stop; 

- -~___find; 

ifldec«l)  then  go  to  14; 
else  if  (dec=2)  then  go  to  15; 
end ; 

lf(dec=4)  then 

do;  put  skip  list("tnter  number  of  years  with  new  budgets"); 
get  lis t (nchange  ) ; 
do  i=l  to  nchange; 

put  skip  list(J,Enter  year,  new  budget"); 
get  1 lst( ny, budget ) ; 
poo  n»ny-78; 

-  57n)«budgetl 

end; 

go  to  16; 
end; 
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p 


II  A)  j 

indl=6i 

if ( i rem“=0)  then  lndl-lremi 
npe=Oi 

put  sklp(2)i 

exp7=exp3  I! relation  I !exp4i 
3 O  do  1=1  to  index! 

put  skip  edi  t(“***SECHEi'***u  .“Page11 ,  i  )  ( col  ( 40)  ,a ,  sk  ip,  col  l  /5),a,f (2>>  i 
put  skip  edlt(“Allocatlon  report  of  mission  area  ",suoma,“  using  ,  ma ,  “  data1')* 
put  skip  edit(“Cost  in  thousands  of  dollar s“ )( col ( 30) ,a ) t 
index l— 61 

if(i=index)  then  indexl=indli 
do  li  =  l  to  index  1 1 
npe=npe+ 1  I 

pe=penum( igr ( j  s ( npe  ) ) )  t 
al t=progal t ( Js (npe  > ) ! 

_ call  dsl_Sretrleve(dbl , •“-range  (c  char)  -select  c ,pe_tl tle-where  ((c.pe=.V.) 

pe.subma, title .code) I 
if(code*=0)  then 

do«  call  com_e rr_< code, “re turning  pe")« 

go  to  1 1 3l 

end! 

call  dsl_Sretr leve(dbl , exp7,pe,appro,al t ,yr I , yr2,yr3,yr4,yr5,yr6,yr /.comment, 
if(code““0)  then  go  to  1131 
call  suincosti 

put  skip(2)  edi t( “PE", "PE  TI  n.E‘',"APPK0  DP  “.“COMMENTS" ) ( x( 5 > , a , x( 1 2 ) , a , 
HO  put  skip  edi t (pe, title, appro, al t .comment )( x( 3 )  a ( 6) , x(2 ) ,a(25 ) , x< 2) ,a( 4 ) ,x ( 5) 
“  put  skip(2)  edi  t ("  1 9 79 I  980" ,  *'  I  981 J  982" ," i  983*' ,"  I  984" ,"  I  98S"  ,“TSIO  "  ,"T5K 
(x(l3),a,x(5),a,x(6>,a,x(6>,a,x(6>,d,x(6>,a,x(6>,a,x(4>,a,x(4),a,x(4),a.x(4), 
put  skip  edi t( “COST" ,yr I tyr2,yr3,yr4,yr5,yr6,yr7, Uw( JJ, jsCnpe ))do  JJ=I  to  ng 
put  sklp(2) I 
113*  end! 

if(l=index)  then  put  skip  edit(J,Total",(sum( l)do  1*1  to  7  ) ) ( x( I ) ,a,x( 3) , ( 7) f ( 1 0 

put  skip  edlt<"***S£CPEr***,,)(skip(3),x<40) ,a) l 

put  skip(2)l 

get  1 is  t (dummy ) I 

end! 

sumcost*  proc! 
sum( I )=sum( I )*yr I  I 
sum(2)«sum(2)*yr2l 
sum(3)*sum(3)*yr3l 
sum (4  >=sum(4 )+yr4i 
sum(b)*sum(5) *yr5 I 
sum<  o)  =  sum( 6) +yr6l 
sum( /)*sum( /) *yr7 ! 
end  sumcost! 

end  output! 

end! 


r  1226  1 ,58b  0.736  55 
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B.  Subroutine  GRAPH 


subrout  Ine  graph!}) 

rommon/romml/  sl<lC>,r(?00,10),nper,}flaq.slack(lU> 
common/ to*»J/  Js<‘0),}l 

lOmmon/comiM/  1qn(‘:0>»1nct200>,cand(rn>»ngr,nvar»lk»1lew(20C.>.ach(.1} 

rommon/commlO/  no»nyr(10>«sum(7>»Zw(50»2‘.i) 

dimens  Ion  y ( 25,  1 0  >  ,  *  C 1  0 )  •  henefl  t  C  25 )  ,  a ( 20 0 ) . y r f 25 . 1 0 ) 

dimension  y(25)«v(2r)«nv(10) 

external  xyplotsinlt (descriptors )»xyplotlbu1td(descr1ptors) 
external  xyplotiplot(descr1ptors),xyptottreset_defaults(descr1ptors) 
rhjracter  t1tle«<i8,xlabet*70»ylabet*20»curve_ndme**0 
character  benn25,cost"22»t1l.26»tpe*27»tse.2i,2z.!il,tle*22 

I  Is  number  of  sets  of  data  to  be  graphed. 

nor  Is  the  total  number  of  proqram  alternatives, 
nper  Is  the  number  of  budget  periods, 
nr:  Is  the  number  of  goals. 

II  Is  the  number  of  selected  pe  alternatives. 

i<1>  Is  the  total  cost  of  the  solution  for  strategy  ). 
lenetlt(m)  Is  the  benefit  of  the  solution  to  task  m. 
yr(i.J)  Is  the  cost  If  the  Jth  solution  In  the  1th  year. 
y(1«])  Is  'eneflt  of  Jth  strategy  to  1th  goal. 

sunt  i)  Is  the  cumulative  cost  of  current  strategy  for  budget  period  1.  1  =  1.7. 
2(1, J)  Is  benefit  to  Jth  goal  of  1th  variable.  1=l,nvar  l  J=l,ng. 

xt  1*1 >=U.O 
do  2  1=1. nper 
yr  (  l  .  JO  ):0. 0 
cont Inue 

compute  total  and  yearly  costs  for  solution. 

1o  5  1  =  1  .nper 
do  5  1  =  1  •  J  l 

«(  1*1 )  =  x( }«1 >»c(  1s(  1), l > 
yrtl,j*n=yrtl,J.n*c(Js(1),l) 
cont  Inue 

writ  etc, 6)  X  f  J  *  1  ) 

format!"  "."The  total  cost  of  the  solution  Is". 112. 21 

compute  task  benefits  of  solution, 
lo  10  m  =  1  .  nq 
y  f  m . 1.11=0.0 
.lo  H  1=1  .Jl 

yfm. '♦l)=y(*.}<l).2w(Js(1),m) 
ront Inue 

’o  11  m  1 « ng 

writ  (6.12)  m,y(m,J«l> 

'ontlnuc 

form.t  (*  ",‘x.  •  benefit  to  task", 15,"  =",110.2  > 

print  ,  "'o  you  want  the  output  from  this  strategy 

saved  for  graphs?  Please  answer  yes  or  no." 

read  (5,220)  answer 
form.it  (a’) 

If ( answer. eg.  "no")  no  to  1000 


! 


i 


t  =  j.i 
n  'll  :nq*  1 
y«mlti>s0.0 
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•  compute  su*  of  benefits  for  this  strategy, 
do  1*  1=1  «no 

yCnql»J)=ytnql»1>"yl1»J> 

1  «  eont Inur 

print  »"oo  you  want  to  generate  more  data  before  constructing  graphs?" 

rea d<5,220>  answer 

Ifl.nswer  .eg.  "yes")  go  to  1000 

n 1  =  nq  •  1 

1  continue 

print  ."'o  you  want  any  graphs  of  total  solution  costs  summed  over 
all  years  vs.  benefit  of  solution  to  Individual  tasks?" 

read(h,20>  answer 

2  format l «3 ) 

Iffanswer  .eq.  *no")no  to  tri 
print  .“rey  In  1nde»  for  the  task." 
read  (5.)  1 


do  27  1=1.1 
2  f  l  ) -y ( 1 »l > 

2  >  cont Inur 
• 

.  1 1  <  t  .30)  <  s  C  l  I  .  I  =  1  .  1  > 

3  formatf"  ", "solution  cost  dat a", 30 < f 12.2»2» > > 
wrltefb  .31)  I y ( 1 . I  )  »  l  =  1  .  1  • 

3)  formatf"  "."solution  benefit  daf a* .30  I f 1 2 . 2. 2 »  ) ) 

/2  =  "Total  solution  cost  ws.  benefit  For  task* 

encode f t It  le . 35 )  22.1 

Vi  form'itfaOO.IS) 

' en=*henet1t  to  task" 
en c ode < y  l abe 1 . 3?  )  ben.1 
3  form  itlalti. 131 

* t abe l=* Tota l  solution  costfln  millions!" 
call  *yol of *1n1 1 (?. 1 1 1 1 e.klabel .ylabet  .1  l  ) 

call  »yo lots  reset _def aul t si  0 .0 .0 ." secret ". 1 . •  ’.0.10.0."  ".Ill 
call  sy p 1 o t Sbu 1 1 d ( I . » . 2 .0 1 ."  ".l.lll 
call  sypl oti plot f 1 1 ) 

1  0  continue 

oo  to  19 

1  1  continue 

print  ,«  o  you  want  a  graph  of  total  benefit  ws.  total  cost  for  each  strateoy 

readlb.20)  answer 

1f(  nswer  .eq.  "no")  oo  to  206 

■•o  '10  »  -1  ,) 
z  t 1 >  =  y ( nol .k  > 

110  root  1 nue 

writ  ft  ,  ’0)  f  »  <  l  >  .1  -  1,  J  > 
writ-  (f>  .31)  fyfnn  1,1), 1  =  1,1) 

title ="TOT*L  SOLUTION  TOST  w* .  T0T«L  PFNfFl”' 
slab  l="'otal  solution  costiln  millions)" 
v  t  ..be l  ‘  'Tenet  It* 

c  II  »yi'lott1n1ti2.t1tle,«ti'bel.ylabel»tl) 

C..II  »yi'  l  ot  )  rese  t  _dr  f  aul  t  s  (  0 , 0 , 0  ," -e  r  re  t  "  »  1  »"  "»r»10.0,"  ".II) 
call  »ypl  ot  S  Pul  l 'If  J  »  *  »2 .01  *"  ",1«H> 


call  xyplot fplo 1 1  ll  ) 

2 '  f  font  1 nu< 

211  r  on  1 1nu<* 

crlnt  o  you  want  any  qraphs  ot  cost  ot  Individual  budget  periods 
v».  Individual  task  benefits?* 
read<5.?n)  answer 
Iflanswer  .eo.  “no")  oo  to  3  r  l 
print  ."fey  In  budnet  period  desired.* 
read ( b«  >  1 

print  t*>ey  In  task  benefit  Index.* 
read  <  b. )  n 


writ)  (6.211)  1  .n 

211  format!"  *«*io  be  plotted  Is  a  a  graph  ot  cost  of  year*.13»* 
vs.  benefit  to  task**13»*  .*) 

lo  214  k  - 1  •  J 
7  <  k )  -  y  (  n«  k  > 
v<  k  )  -  yr (  l.k  ) 

214  continue 
• 

w  r  1 1  r ( 6  .’01  Cyril. tl.l-l.J) 
wrlt-Cb  .31)  CyCn.l )tl:l.|) 

1 1 1 1 .  -  "  • 
xlabelr"  * 
cost=“Cost  of  year* 
en code ( « l abe l . 232 )  cost.1 

232  fore  t ( al2,1P) 

t.en: "Penef  1 1  to  task" 
enc ode ( y labe l . 233)  ben.n 

233  format l al5. 12) 
tle:-COST  OF  YF  A  P " 
encorie(t1l.234)tle.1 

234  f orm -t  (al2. 1  3) 

tse:«  vs.  BFNFFIT  TO  TASK* 
enroot < t pe. 2 35)  tse.n 

235  form  it  Ca20.13) 

encode c t 1 t l e . 236 )  tll.tpe 

236  t o rm  . t ( al 5. #24 ) 

call  xyplotSln1t(2. title. xlabel.ylabel.il) 

call  xypl o t treset _de f aul t s ( 0 .0 . 0, *se c re t *.  1  . *  ■» 0.10.0.*  *  *  l  l  ) 
call  xyplotSr-ulldT J.v.z.01.*  *.l,ll) 
call  xyplotSplot(ll) 

’75  continue 
3  0  0  rontC  npe 
•  1 

31  < ont Inur 

print  ."'o  you  want  graphs  showing  cost  of  strateay  for  each  budget  period?* 

readCS.lT)  answer 

If  (  nswcr.eq.  *no">  r.o  to  4rl 

/!  =  *  * 

'•o  311  1  =  l.nper 
v<  1  )  rr  f  l  o-  t  Cny  r  ( 1 ) ) 

311  coni Inue 

« l abe l c "h urtqet  Period* 
yl abel ="Cost " 
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Z  2  =  " C  OST  vs.  BUDGET  PERIOD  FOR  STRATEGY" 
do  375  n:li| 
do  120  1=l«nper 
i(11=yrlUn) 

5.0  continue 

encode ( t 1 t { e« 325 >  zz«n 
3;’S  1or»r t la35«15> 

* 

call  Kyplotltn1t(2*t1tle«Klabel«ylabel*lll 

Call  xy pi o 1 1  rest l _detau 1 1 s l 0 « 0 « 0 « • se cr 1 t • . 1» ■  *%0«10.0*"  "till 
call  xy  p  l  o  t  tbul  l  d(  nper  «  v  «  z«0  1  »•  'iljilll 
call  xyplo t S pt ot I l l > 

>7=12*1 

'75  continue 

A  1  continue 
* 

call  xyplotinone 

Isn 

1  00  continue 
r  lose  ( <• ) 
return 
end 


lrTCPPl  >urtrt>RD*  i*>At  >f  l  #rv>z»r  .f  ort  ran 
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I.  INTRODUCTION 


This  volume  is  one  of  four  that  document  ANSER's  develop¬ 
ment  of  R&D  resource  allocation  methodology  (RAM)  for  the 
Director  of  Program  Integration,  AF/RDX .  Volume  1  provides 
an  overview  of  the  work  and  its  applications.  Volume  2  de¬ 
scribes  the  RAM  technique  and  how  to  use  the  general-purpose 
computer  programs  that  incorporate  it.  Volume  3  describes 
how  to  use  the  interactive  computer  program  developed  for  use 
of  the  RAM  within  AF/RDX,  and  Volume  4  describes  the  way  in 
which  we  tested  its  computational  performance.  Each  volume 
emphasizes  some  particular  aspect  of  our  research  and  can  be 
read  independently  of  the  others. 

In  this  volume,  we  describe  the  results  of  our  test  program 
and  document  the  way  we  conducted  the  tests.  Chapter  II  con¬ 
tains  our  test  plan,  test  results,  and  the  inferences  we  can 
make  from  the  results.  In  Chapter  III,  we  document  the  pro¬ 
cedures  we  used  to  make  the  tests.  The  results  are  readily 
understandable,  although  some  knowledge  of  statistics  would  be 
helpful  in  understanding  how  we  made  inferences  from  the  test 
data.  The  test  procedures  are  of  narrower  interest  and  are 
documented  primarily  for  our  use  in  any  further  testing.  They 
may  be  of  some  value,  however,  to  others  engaged  in  similar 
tests . 

The  primary  reason  for  testing,  other  than  to  find  any 
mistakes  in  the  software,  is  to  verify  that  the  computer 
programs  can  handle  the  problems  likely  to  be  encountered. 
Capability  is  measured  by  determining  the  accuracy  the  program 
can  achieve  and  the  computer  resources  it  requires  as  a  function 
of  problem  size  and  complexity.  We  are  satisfied  that  RAM/VM 
and  RAM/GP  (as  defined  in  Volume  2  of  this  report)  provide  an 
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excellent  capability  for  routine  use  in  the  problems  that 
are  likely  to  occur  in  AF/RDX.  Both  programs  have  also 
performed  well  in  other  applications  (see  Volume  1).  However, 
we  still  do  not  know  all  the  limits  of  this  software,  since 
the  cost  of  determining  them  would  be  prohibitive.  Evaluation 
is  difficult  because  we  know  of  no  other  similar  computer 
program  that  will  accomplish  the  same  tasks.  Consequently, 
we  can  only  compare  the  results  of  our  work  with  the  results 
of  commercially  available  programs,  which  have  less  capability 
and  must  use  simplified  test  problems.  To  achieve  a  higher 
level  of  confidence  would  require  a  substantially  more 
expensive  test  program.  We  believe  we  have  achieved  an 
acceptable  level  of  confidence  with  the  testing  done. 
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II.  COMPUTATIONAL  TEST  RESULTS 


A.  Test  Plan 

After  running  the  resource  allocation  algorithms  on  the 
Multics,  we  decided  to  formulate  and  carry  out  a  test  plan 
to  evaluate  the  computer  programs.  The  testing  process  had 
several  goals.  First,  it  was  to  verify  the  logic  of  the 
software.  Second,  the  testing  process  was  to  define  any 
limitations  on  the  size  or  complexity  of  the  problems  that 
the  programs  could  be  expected  to  handle.  Finally,  it  was 
to  define  conditions  under  which  one  programmed  algorithm 
would  be  preferable  to  another. 

The  test  plan  used  the  Control  Data  Corporation's  (CDC) 

APEX  package,*  a  linear  programming  package  that  can  solve 
integer  programming  problems.  Unlike  our  resource  alloca¬ 
tion  programs,  the  APEX  cannot  perform  goal  programming. 

However,  because  we  knew  of  no  other  suitable  alternative, 
we  chose  APEX  as  the  standard  against  which  the  performance 
of  our  programs  would  be  measured.  We  therefore  did  not 
use  the  goal  programming  capabilities  of  our  programs. 

The  testing  procedure  consisted  of  running  randomly  gen¬ 
erated  problems  in  each  of  several  problem  sizes  for  each  of 
our  RAM  programs +  and  the  APEX.  The  test  problem  size  was 
the  number  of  decision  variables  (alternatives  to  be  con¬ 
sidered  in  the  resource  allocation)  for  a  problem.  We 
devised  random  problems  by  using  a  random  number  generator 
to  supply  coefficients  for  problems  with  a  specified  number 
of  decision  variables.  Then  for  each  trial  problem,  we  compared 

*  Hereafter,  we  refer  to  the  package  simply  as  APEX. 

+  We  also  used  our  MIP2  program  (see  section  II. B) ,  but 
since  we  dropped  the  program  partway  through  the  testing 
it  is  not  considered  a  significant  part  of  the  procedure. 
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and  evaluated  outputs  for  each  of  the  RAM  codes  with  those 
for  APEX.  We  drew  our  conclusions  from  a  statistical  analysis 
of  the  results  as  well  as  from  objective  qualitative  analysis. 
Finally,  we  tried  to  find  standard  test  problems  used  by  the 
operations  research  community  against  which  to  test  the  RAM 
codes,  but  we  were  not  successful. 

We  encountered  two  principal  difficulties  during  the  testing 
process.  First  the  use  of  APEX  constrained  the  testing  because 
it  could  not  handle,  at  an  affordable  cost,  problems  of  the  size 
needed  in  our  test  procedure.  Instead  of  comparing  the  results 
of  our  programs  with  APEX  results  for  problems  involving  100  to 
300  decision  variables,  we  had  to  limit  comparisons  to  problems 
with  less  than  50  variables.  Even  for  the  smaller  problems,  APEX 
could  not  guarantee  an  optimal  solution,  but  rather  a  solution 
within  several  percent  of  optimum.  The  second  difficulty  was 
the  lack  of  a  standard  against  which  to  measure  goal  programming. 
We  are  not  likely  to  resolve  this  problem  without  development  of 
additional  independent  goal  programming  algorithms. 

B.  Test  Results 

Three  RAM  programs  were  evaluated  in  the  tests:  RAM/VM, 
RAM/GP,  and  MIP2.  MIP2  was  our  early  experimental  version  of 
the  resource  allocation  methodology,  which  was  based  on  a  variant 
of  a  simplex  linear  programming  algorithm.  Although  this  model 
will  not  be  used  in  the  future,  partially  as  a  result  of  these 
tests,  the  results  are  included  here  for  comparison.  RAM/VM 
and  RAM/GP  combine  elements  of  goal  programming  and  linear  0-1 
programming  and  use  the  direct  solution  technique  described  in 
Volume  2.  RAM/VM  seeks  the  resource  allocation  that  maximizes 
the  overall  benefit  received  subject  to  resource  constraints. 
RAM/GP  seeks  the  allocation  that  minimizes  deviations  from  a  set 
of  specified,  quantitative  objectives.  Both  use  a  priority  system 
for  optimizing  classes  of  objectives. 
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Table  1  shows  the  results  of  the  trials  of  the  RAM/GP, 
RAM/VM,  MIP2,  and  APEX  programs.  For  each  trial,  the  same 
randomly  generated  problem  was  run  on  each  of  the  four  pro¬ 
grams.  On  three  occasions,  the  APEX  did  not  obtain  a  solution 
within  the  specified  time. 

The  column  labeled  "Percentage  of  Optimum  (APEX) "  indi¬ 
cates  within  what  percentage  of  optimum  the  APEX  solution  was 
guaranteed.  In  Trial  5,  for  example,  the  best  APEX  solution 
found  is  guaranteed  to  be  within  5.89  percent  of  the  value  of 
the  objective  function  at  the  true  optimal  solution.  As  a 
consequence  of  this,  the  product  of  1.0589  and  the  objective 
function  value  (1,363.428),  or  1,443,734,  is  an  upper  bound 
for  the  value  of  the  objective  function  evaluated  at  the  actual 
optimal  solution. 

Note  that  the  MIP2  program  rarely  reached  a  solution, 
returning  instead  a  message  that  the  program  had  been  unable 
to  find  a  feasible  solution.  This  inability  to  find  feasible 
solutions  is  caused  by  the  inability  of  the  program  to  maintain 
required  solution  criteria  for  each  interaction.  It  does  not 
indicate  that  the  problem  had  no  feasible  solution.  We  had 
suspected  this  problem  before  testing  but  had  not  realized  its 
extent  until  partway  through  the  testing  procedures.  When  the 
MIP2  program  did  find  a  solution,  it  matched  those  found  by  the 
other  programs.  However,  we  decided  that  the  extent  of  MIP2's 
inability  to  find  feasible  solutions  warranted  dropping  it  from 
the  testing  plan. 

We  applied  the  Wilcoxon  Matched-Pairs,  Signed- Rank  test 
to  the  data  in  Table  1.  We  used  this  nonparametric  statistical 
test  to  compare  the  results  that  RAM/GP  and  RAM/VM  provide  with 
those  provided  by  APEX.  The  advantage  of  the  nonparametric  test 
for  paired  differences  is  that  it  does  not  require  the  assumption 


TABLE  1 

SUMMARY  OF  TRIAL  RESULTS 


Trial 

Number 

Number 

of 

Value  of  Objective  Function  at 

Best  Solution  Obtained 

Percentage 

of 

Optimum 

(APEX) 

Variables 

RAM/GP 

RAM/VM 

1 

MIP2 

APEX 

1 

n 

630.952 

Not 

Run 

— 

630.952 

1.14 

HI. 

631.946 

— 

604.211 

9.50 

18 

1,461.984 

1,492.763 

1,492.703 

Optimal 

4 

21 

1,689.535 

1,689.535 

1,689.520 

1,689.535 

Optimal 

5 

21 

1,380.276 

1,380.276 

NFS* 

1,363.428 

5.89 

6 

21 

1,265.859 

1,265.859 

NFS 

1,265.859 

5.97 

7 

21 

1.453.479 

1,453.479 

NFS 

1, 417.578 

6.72 

8 

21 

1,354.015 

1,354.015 

NFS 

1,232.959 

9.49 

9 

21 

1,467.194 

1,467.194 

NFS 

1,467.194 

1.25 

10 

21 

1,513.992 

1,513.992 

NFS 

1,513.992 

11 

21 

1,185.199 

1,185.199 

NFS 

1,185.199 

1.40 

12 

21 

1,361.286 

1,361.286 

NFS 

1,361.286 

3.05 

13 

2, 

1,073.619 

1,073.619 

NFS 

1,047.597 

7.83 

K| 

SB 

2,510.933 

2,510.933 

NFS 

2,393.704 

4.18 

mM 

El 

2,735.956 

2,735.956 

NFS 

2,735.054 

3.14 

Bl 

45 

2,854.954 

2,854.954 

— 

2,869.605 

3.54 

17 

45 

2,584.174 

2,584.174 

— 

2,584.174 

1.22 

18 

45 

3,095.392 

3,095.392 

— 

3,095.392 

1.19 

19 

45 

2,339.578 

2,339.578 

— 

mm 

45 

2,220.971 

2,220.971 

— 

2,179.195 

3.71 

WM 

45 

2,500.680 

2,500.680 

— 

22 

45 

2,499.623 

2,499.623 

— 

2,622.231 

0.42 

*No  feasible  solution. 
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that  the  underlying  population  of  differences  is  normally 
distributed.  The  nonparametric  test  makes  no  assumption 
about  the  population  distribution.  We  could  not  divide 
the  trials  into  groups  according  to  the  number  of  variables 
because  the  resulting  data  sets  would  not  be  large  enough 
to  be  statistically  meaningful. 

Table  2  shows  the  data  for  applying  the  Wilcoxon  Matched- 
Pairs  /  Signed  Rank  Test  to  the  values  of  the  objective  functions 
provided  by  RAM/GP  and  RAM/VM.  The  test  is  carried  out  in 
terms  of  the  paired  differences,  d  =  x-^  -  X2,  where  the  d 
values  represent  differences  between  two  observations  on 
the  same  individual  or  object.  In  this  case,  the  difference 
is  between  the  results  obtained  by  two  computer  programs 
given  the  same  randomly  generated  problem.  The  absolute 
values  of  the  differences  are  ranked  from  1  to  n,  with  the 
smallest  difference  being  assigned  the  rank  of  1.  Each  rank 
is  then  given  the  sign  (either  +  or  -)  of  the  associated 
value  of  d.  If  there  are  ties  in  ranking,  the  mean  rank 
value  is  assigned  to  the  tied  items.  If,  for  example,  the 
sixth  and  seventh  ranked  items  are  tied,  a  rank  of  (6  +  7)/2  = 

6.5  is  assigned  to  each.  If  the  difference  between  paired 
observations  is  0,  that  item  is  dropped  and  the  number  of 
differences  reduced  by  one.  Since  Table  2,  has  10  zeros  in 
the  difference  column,  the  effective  sample  size  is  20  -  10  =  10. 

As  indicated  in  the  last  two  columns  of  Table  2,  the 
sums  of  the  ranks  are  obtained  separately  for  the  positive 
and  negative  differences.  These  sums,  I  ranks  (+)  and 
Z  ranks  (-) ,  form  the  basis  for  the  null  hypothesis  H^: 
l  ranks  (+)  =  Z  rank  (-) .  Specifically,  the  null  hypothesis 
is  that  the  positive  and  negative  differences  in  the  population 
are  symmetrically  distributed  about  a  mean  of  0.  The  smaller 
of  the  two  ranked  sums  is  called  Wilcoxon's  T  statistic  and  is  the 
test  statistic.  Hence,  in  Table  2,  the  test  statistic  is  T  = 

Z  raa’  (-)  *  16. 
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TABLE  2 

DATA  FOR  THE  WILCOXON  MATCHED-PAIRS,  SIGNED-RANK  TEST 


Trial 

Number 


RAM/GP 

Solution 

*1 


630.952 

631.946 

1,461.984 

1,689.535 

1,380.276 

1,265.859 

1,453.479 

1,354.015 

1,467.194 

1,513.992 

1,185.199 

1,361.286 

1,073.619 

2,510.933 

2,735.956 

2,854.954 

2,584.174 

3,095.392 

2,220.971 

2,499.623 


APEX 

Solution 

X, 


1,492.763 

1,689.535 

1,363.428 

1,265.859 

1,417.578 

1,232.959 

1.467.194 
1,513.992 
1,185.199 
1,361.286 
1,047.597 
2,393.704 
2,735.956 
2,869.605 
2,584.174 
3,095.392 

2.179.195 
2,622.231 


Difference 
d  =  X,  -  X2 


r 


Table  3  gives  the  critical  values  of  T.  For  sample  size 
N=10  at  the  0.10  level  of  significance,  T  can  be  no  greater 
than  10.  Note  that  Table  3  presents  the  maximum  values  T  can 
have  and  still  be  considered  significant  at  the  stated  signif¬ 
icance  level.  Thus,  since  the  calculated  value  of  T(16) 
exceeds  10,  we  cannot  reject  the  null  hypothesis  of  identical 
population  distributions.  Hence,  we  concluded  that  the  per¬ 
formance  of  RAM/GP  and  RAM/VM  did  not  differ  significantly 
in  the  values  obtained  for  the  objective  functions  for  the 
trial  problems.  We  reached  the  same  conclusion  when  comparing 
RAM/VM  with  APEX  and  RAM/GP  with  APEX. 

The  value  of  these  results  is  obscured  by  the  lack  of 
certainty  as  to  whether  APEX  was  achieving  optimal  solutions 
for  the  trial  problems.  That  APEX  guarantees  a  solution 
to  be  within  a  specified  percentage  of  optimum  does  not  mean 
that  the  solution  is  not  optimal.  Nevertheless,  except  for 
Trials  3  and  4,  we  cannot  prove  that  the  solutions  are  optimal. 

Table  4  presents  upper  bounds  for  the  value  of  the  ob¬ 
jective  function  at  optimal  solutions  and  the  ratio  of  the 
RAM/GP  solution  to  the  upper  bound.  For  21-variable  problems, 
the  mean  of  the  ratios  is  0.973  with  a  standard  deviation  of 
0.22  and  variance  of  0.0004.  For  45-variable  problems,  the 
mean  of  the  ratios  is  0.977  with  a  standard  deviation  of  0.019 
and  variance  of  0.0003.  The  overall  mean  of  the  ratios  is  0.975 
with  a  standard  deviation  of  0,020  and  variance  of  0.0004. 

Using  this  information,  we  can  establish,  for  the  overall  set 
of  22  samples,  a  confidence  of  0.995  that  70  percent  of  the 
sample  distribution  of  ratios  are  between  the  values  of  0.944 
(minimum  value  occurring)  and  1.007  (maximum  value  occurring). 

We  can  establish  a  confidence  of  0.95  that  80  percent  of  the 
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TABLE  3 

CRITICAL  VALUES  OF  T*  IN  THE 
WILCOXON  MATCHED-PAIRS,  SIGNED-RANK  TEST 


differences  that  are  all  of  the  same  sign.  For  any  given  N  (number 


of  ranked  differences),  the  obtained  T  is  significant  at  a  given  level 


if  it  is  equal  to  or  less  than  the  value  shown  in  the  table. 


TABLE  4 

STATISTICS  ON  SOLUTION  RATIOS 


r 


Trial 

Number* 

Number 

of 

Variables 

RAM/GP 

Solution 

RAM/VM 

Solution 

APEX 

Solution 

Percentage 

of 

Optimum 

(APEX) 

Upper 
Bound  T 

RAM/GP 
Upper 
Bound T 

Statistics 

for 

Ratio 

1 

12 

630.952 

— 

630.952 

1.14 

638.145 

0.989 

2 

15 

631.946 

— 

604.211 

9.50 

661.611 

0.955 

3 

18 

1,461.984 

— 

1,492.763 

Optimal 

1,492.763 

1.000 

4 

21 

1,689.535 

1,689.535 

1,689.535 

Optimal 

1,689.535 

1.000 

5 

21 

1,380.276 

1,380.276 

1,363.428 

5.89 

1,443.734 

0.956 

6 

21 

1,265.859 

1,265.859 

1,265.859 

5.97 

1,341.431 

0.944 

M  =  0.9730 

7 

21 

1,453.479 

1,453.479 

1,417.578 

6.72 

1,512.839 

0.961 

J  =  0.0220 

8 

21 

1,354.015 

1,354.015 

1,232.959 

9.49 

1,349.967 

1.003 

J2  =  0.0004 

9 

21 

1,467.194 

1,467.194 

1,467.194 

1.25 

1,485.534 

0.988 

10 

21 

1,513.992 

1,513.992 

1,513.992 

3.56 

1,567.890 

0.966 

11 

21 

1,185.199 

1,185.199 

1,185.199 

1.40 

1,201.792 

0.986 

12 

21 

1,361.286 

1,361.286 

1,361.286 

3.05 

1,402.805 

0.970 

13 

21 

1,073.619 

1,073.619 

1,047.597 

7.83 

1,129.624 

0.950 

14 

45 

2,510.933 

2,510.933 

2,393.704 

4.18 

2.493.671 

1.007 

15 

45 

2.735.956 

2,735.956 

2,735.054 

3.14 

2,820.935 

0.970 

M  =  0.9770 

16 

45 

2,854.954 

2,854.954 

2,869.605 

3.54 

2,971.189 

0.961 

J  =0.0190 

17 

45 

2,584.174 

2,584.174 

2,584.174 

1.22 

2,615.701 

0.988 

J2  =  0.0003 

18 

45 

3,095.392 

3,095.392 

3,095.392 

1.19 

3,154.204 

0.981 

20 

45 

2,220.971 

2,220.971 

2,179.195 

3.71 

2,260.043 

0.983 

22 

45 

2,499.623 

2,499.623 

2,622.231 

0.42 

2,633.244 

0.949 

M  =  0.9750 


J  =  0.0200 
J2  =  0.0040 

•Trials  19  and  21  are  omitted  because  APEX  did  not  reach  a  solution, 
t  Computed  by  multiplying:  1.0  +  percentage  of  optimum  (APEX)  x  APEX  solution. 

TOO 

Thus,  for  trial  22.  2,633.244  =  (1.0042)  x  (2,622.231). 

The  occurrence  of  meaningful  values  greater  than  1.0  among  entries  in  this  column  is,  by  definition  of  upper  bound, 
impossible.  Nevertheless,  they  occur.  We  do  not  know  whether  they  are  a  result  of  roundoff  error,  errors  in  the 
returned  value  of  percentage  of  optimum  (APEX),  or  of  other  causes.  Since  we  did  not  know  the  cause  of  entries 
greater  than  1.0,  we  did  not  tamper  with  data  by  resetting  the  value  of  such  entries  to  1 .0. 
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distribution  of  ratios  are  greater  than  0.944.  These  values  are 
taken  from  standard  tables  of  nonparametric  tolerance  limits.* 

These  results  indicate  that  a  user  of  RAM/GP  or  RAM/VM, 
can  have  a  high  degree  of  confidence  that  results  from  these 
programs  are  reasonably  close  to  optimum  for  problems  involving 
no  more  than  45  decision  variables.  However,  we  have  no  basis 
for  extrapolating  these  results  to  larger  problems. 

Figure  1  shows  the  average  time  used  by  RAM/GF,  RAM/VM, 
and  MIP2  to  complete  a  problem  as  a  function  of  the  number  of 
decision  variables  within  the  problem.  The  figure  implies  that 
the  RAM/GP  program  has  a  reasonable  running  time  for  problem 
sizes  of  200  to  250  decision  variables.  For  RAM/VM,  the  run¬ 
ning  time  would  be  considerably  less  for  problems  of  the  same 
size.  The  sketchy  data  for  MIP2  seem  to  indicate  that  this 
program  would  be  too  slow  to  run  very  large  problems. 

The  conclusions  that  we  can  draw  from  the  test  results 
are  reasonably  clear.  The  RAM/GP  and  RAM/VM  programs  may  be 
used  with  confidence  in  problems  that  have  up  to  45  decision 
variables  and  that  do  not  involve  any  goal  programming.  The 
results  obtained  may  or  may  not  be  optimal,  but  they  will  in 
all  likelihood  be  quite  close  to  optimal.  The  testing  procedure 
could  not  evaluate  the  optimization  capability  of  RAM/GP  and 
RAM/VM  for  problems  larger  than  45  decision  variables  or  for 
those  involving  goal  programming.  The  MIP2  program  was  found 
to  be  incomplete  and  unsuitable  for  use. 


R.  E.  Walpole  and  R.  H.  Myers,  Probability  and  Statistics  for 
Engineers  and  Scientists,  2nd  Ed.,  New  York:  MacMillan  Pub¬ 
lishing  Co.,  Inc.,  1978. 
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FIGURE  1 

TIME  USED  TO  COMPLETE 
PROBLEM  AS  A  FUNCTION  OF  PROBLEM  SIZE 


20  40  60  80  100  120 

Number  of  Decision  Variables 


140  160 


180 


Unfortunately,  we  could  not  meet  all  the  test  program 
objectives.  However,  even  the  limited  results  obtained  are 
useful  in  developing  some  confidence  in  the  programs  and  reason¬ 
able  expectations  for  their  performance. 


III.  TEST  PROGRAM  OPERATION 


A.  Test  Problem  Generation 


The  problems  generated 
following  form: 

Minimize : 


for  the  test  program  took  the 


NG 

Z  =  I  w .n  . 

j=l  3  3 


Subject  to: 


NVAR 


i=l 


C.  X.  <  B 
im  i  -  m 


m  =  1,NPER 


NVAR 


I  a.  .  X.  +  n.  >  A. 
i-1  ^  1  3  -  3 

3 

=  1 ,  NG 

Z  X.  <  1 

X.EGR 

1  X 

k 

=  1 ,NGR 

X.  e  (0,1)  Vi 

l 

i 

=  1 , NVAR 

n.  >  o  V. 

3  -  3 

j 

=  1 ,  NG 

An  input  generator  was  developed  that  created  a  set  of 
pseudorandom  numbers  and  formatted  them  to  be  used  as  input 
data  by  RAM/VM  and  RAM/GP.  The  input  generator  created  a 
"problem"  based  on  a  set  of  given  parameters  and  a  "seed." 

The  seed,*  which  was  given  a  unique  value  for  each  problem, 
was  the  basis  for  the  random  number  generator.  The  parame¬ 
ters  for  the  input  generator  were  the  number  of  (a)  0-1 
variables  (NVAR) ,  (b)  goals  (NG) ,  (c)  mutually  exclusive 
groups  (NGR) ,  (d)  priority  levels  (NP) ,  and  (e)  time  periods 
and  values  for  Bm  (m=l,NPER) .  The  values  for  A ^  ( j=l,NG) 
were  based  on  the  value  of  the  parameter,  NGR  (for  most  test 
problems,  Aj=119NGR) .  The  random  number  generator  provided 

the  values  for  the  coefficients  C.  and  a .  . . 

im  i  j 

•For  an  explanation  of  the  use  of  "seed"  numbers  in  generating 
random  numbers,  see  Thesen,  Arne,  Computer  Methods  in  Operations 
Research,  New  York:  Academic  Press,  1978. 
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All  test  problems  had  four  goals  <NG=4) ,  one  priority 
level  (NP=1) ,  four  times  periods  (NPER=4) ,  and  three  0-1 
variables  in  each  mutually  exclusive  group  (therefore, 
NVAR=3*NGR) .  NVAR  and  NGR  were  varied  during  the  test  program 
that  determined  the  size  of  the  problem.  Unique  sets  of  co¬ 
efficients  (C.  and  A. .)  were  generated  for  each  nroblem. 
im  lj 

Within  each  problem  size,  the  values  for  B  were  also  varied. 

m 

Table  5  shows  a  sample  problem  created  by  the  input  generator. 


TABLE  5 

SAMPLE  DATA  CREATED  BY  INPUT  GENERATOR 


6 

4  1 

1 

1  1 

92.480 

20.398 

57.644 

£  1.867 

79.913 

9  0.6  33 

7.520 

38.274 

1 

1  1 

1 

£  3 

30.000 

45. CC0 

42.017 

£8.396 

9.036 

64.670 

49 • 36£ 

79.290 

£7.228 

44.428 

233. CCC 

238.000 

4  £  1 

1  1  1 


9.036 

64.670 

49.860 

79.290 

£7.228 

44.428 

44.577 

17.664 

2  £ 

2 

1  £ 

3 

35. C0C 

40.000 

13.482 

8.219 

32.761 

35. 364 

90-694 

92. 023 

£.967 

36.395 

236.000  2 

38.000 

1  1 

3£ • 76 1  35 • 364 

90.594  92.023 

2.967  36*395 

56.538  86.691 


92.460  20.398 

57.644  21.867 

79.913  90*533 

7.526  36.274 
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Because  the  input  generator  created  the  problems  in  a 
format  compatible  with  RAM/VM  and  RAM/GP,  we  had  to  develop 
preprocessors  (reformatting  programs)  to  input  the  same 
problems  to  MIP2  and  APEX.  These  preprocessors  read  in  the 
data  as  created  by  the  input  generator  and  reformatted  it  to 
be  compatible  with  MIP2  and  APEX.  Table  6  shows  the  data 
provided  in  Table  5  as  reformatted  for  APEX. 

Listings  of  the  computer  codes  that  generated  the  data 
and  reformatted  them  are  available  from  ANSER.  The  codes 
used  were  implemented  on  the  CDC  system.  Minor  changes 
have  been  made  in  the  coding  to  make  it  compatible  with  the 
CDC  system  and  to  ensure  that  the  problems  generated  for  APEX 
were  the  same  as  those  generated  on  the  Multics  system  for 
RAM/VM  and  RAM/GP. 

B.  Test  Problem  Solution 

APEX  is  a  commercially  available  optimization  program 
developed  by  CDC  for  use  on  their  operating  systems.  During 
the  test  program,  we  used  the  APEX  Mixed  Integer  Programming 
option.  This  option  uses  a  branch-and-bound  algorithm  to 
solve  the  mixed  integer  problem. 

1.  Run  Specifications  for  the  Test  Program 

We  ran  APEX  as  a  batch  job  and  submitted  the  problems 
using  either  a  "single  solve  card"  or  a  "control  program." 
Examples  of  the  input  files  for  each  are  shown  in  Tables  7 
and  8. 


•All  development  and  applications  of  RAM  programs  were  done 
on  the  Multics  computer  system  as  installed  on  the  Air  Force's 
Honeywell  Series  68/Level  60  computer. 
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TABLE  6 

DATA  FORMATTED  FOR  APEX  USE 


KAM  KORA 

f.cws 

U  OLJfU.C 

L  JCp.CW 

l  rcp.ov 

L  3CRGW 

L  ACfcGV 

l  ISOS 

L  2SGS 

t  1  af-.oi 

C  2Af.0W 

L  3  AP.t  V 

L  4AF.OV 


1  COL 
1CCL 
ICOL 
1  COL 
ICCL 

1  COL 
ICOL 
ICCL 
ICOL 
2CCL 
2CGL 
2C0L 
2CCL 
2C0L 
2CCL 
2C0L 
2C0L 

2  COL 
3COL 
3C0L 
3C0L 
3CGL 

3CCL 

3CCL 

3CCL 

3C0L 

3CCL 

ISC 

ACOL 

4CGL 

aCCL 

4CGL 

AC  OL 

ACOL 

ACOL 

ACOL 

ACCL 


ICRGW 

92.  ASe 

2  C  RlV 

S7-6AA 

3CRGW 

79.913 

A  CROW 

7-S2C 

IAROW 

A2.CI7 

2ARGV 

9  •  C  36 

3  ARGW 

A9-86C 

AARCW 

£7.226 

ISG5 

1.CC0 

1CP.GW 

22-398 

2  CROW 

£1.867 

3CRGV 

9C-833 

ACF.GW 

38.27A 

1ARCW 

£8.396 

£  ARC  W 

6A.67C 

3ARGV 

79 • 29  C 

A  AP.CW 

A  A  >  A  2  8 

isos 

l.CCC 

1  CROW 

9.836 

2CR0W 

A9.B6C 

3  CROW 

2  7 . 2£8 

A  CROW 

AA.S77 

IARCW 

13-A82 

2  ARGW 

32.761 

3ARCW 

98.694 

AAF.CW 

2.967 

isos 

I.OCO 

ISOS 

i.ecc 

1C  ROW 

6 A .678 

2CF.GV 

79.29C 

3  CROW 

AA.A28 

AC  ROW 

1 7  •  66  A 

1  ARGW 

8.219 

2AR0W 

35. 36a 

3  A  ROW 

92.C23 

AARCW 

36.396 

2  SOS 

1.0C8 

SCOL 

5CGL 

SCOL 

SCOL 

5C0L 

SCOL 

5C0L 

SCOL 

SCOL 

6C0L 

6C0L 

6CGL 

6CGL 

6CGL 

6COL 

6CGL 

6  COL 

SCOL 

2SC 

I  GOV 

2GCV 

3LDV 

ALOV 

RiS 

P.MS 
RHS 
RJiS 
RHS 
RHS 
RHS 
RHS 
RHS 
RHS 
P.HS 
bOL'  N  L  5 
SI  LIMITS 

si  limits 

LNLATA 


1C  ROW 

32.761 

2  CROW 

9C.69A 

3CRGW 

2.967 

ACRGW 

S6*633 

IAROW 

92.43 C 

2  ARGW 

57.6AA 

3  ARGW 

79-913 

AARCW 

7-52C 

2  SO  S 

i.cce 

1C  ROW 

3S.36A 

2CF.CW 

92-C23 

3CF.CW 

36*395 

4CRCW 

86-69 J 

IAROW 

2  C • 39  B 

2  A  ROW 

21*867 

3ARGW 

98-033 

AAF.CW 

38.27a 

2SGS 

l.CCC 

2SCS 

l-CCfc 

I  AR.GW 

l.CCC 

2  ARGW 

l.CCC 

3  AP.CW 

l.CCC 

A  AP.CW 

I  .  ccc 

ICRGW 

38.CCC 

2  CROW 

AS. CCC 

3CF.CW 

35. CCC 

AC  ROW 

48. CCC 

1SCS 

1 .  CCC 

2S0S 

1 .  ecc 

1  AF.CW 

238. CCC 

2  A  ROW 

236. ere 

3  ARCW 

23B- CCC 

AAROV 

238*  CCC 

ICOL 

aCOL 

OfcviP  L*NC 
t b%y y  UNC 
CLvf  t'KC 
GtJi  tr.c 


ISC 

2£C 


i.eec 
t.eec 
i.ecc 
i.  ecc 
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TABLE  7 

SAMPLE  INPUT  FILE  FOR  RUNNING  APEX 
USING  "SINGLE  SOLVE  CARD" 
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TABLE  8 

SAMPLE  INPUT  FILE  FOR  RUNNING  APEX 
USING  “CONTROL  PROGRAM" 


CC 1  CL  /JOE 

HAIL  LChl^TSL/F4. 

CC  X  £  C  USLn<  SC  I  C6V£E  /A,  SLCLC,  EL) 
CC  13C  A.TTACE  t  AFEA/UIj  =  Ll  ohAF^Y ) 
CCIAC  LET*  TAPE  1  =  TAFE6  » 

CC1A5  LLF1NL,TLEF. 

CC  ISC  F.F bj  1  CCCC C • 

CC16C  ELLUCL, 

cci7c  afe;-;<c.,sgf=teef) 
cc£  l  c  eayf:le,lay. 

CC  £  £  C  REPLACE*  LAY  • 

cc£3c  l;:xt. 

£C£LC  LAYFILE*LAY. 

CC25C  F.EFLAC£*EAY. 

CC  £6  £  /  EC 


INFUT 

s 

SET 

EE  EXE 

Kir; 

SET 

EE  0  LJ 

SET 

EE  EES 

SET 

SLLLCT 

KEEtiL 

SET 

CF.ASi; 

i-ilEIRT 

F.PGLEEL 

-464 C • 

gutfut 

leit 

FELL 

TLKF 

CC£6 5  /EOF 
CC£7C  /Ecr 
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APEX  can  be  submitted  using  the  "single  solve  card"  for 
most  problems.  The  solve  card  allows  the  user  to  set  the 
direction  of  optimization  (MIN  or  MAX)  and  select  any  of  a 
number  of  options.  Line  00170  of  Table  7  is  an  example  of 
the  "single  solve  card."  "MIN"  informs  APEX  that  the  problem 
being  submitted  is  a  minimization  problem.  "MIP"  directs 
APEX  to  use  the  mixed  integer  programming  option.  The  "SOF" 
option  directs  APEX  to  write  all  output  into  a  direct  access 
file,  defined  here  as  TEMP.  The  "RL"  option  establishes  a 
resource  limit  that,  if  exceeded,  would  cause  APEX  to  dis¬ 
continue  processing  and  exit.  Two  additional  options  that 
should  be  mentioned  are  "OPT"  and  "SV."  "OPT"  directs  APEX, 
when  using  the  MIP  option,  to  find  and  prove  the  optimal 
solution.  If  the  "OPT"  option  is  not  included  as  an  argument 
on  the  solve  card,  APEX  will  terminate  the  search  for  an 
optimal  solution  after  finding  a  solution  within  10  percent 
of  optimum.  "SV"  will  direct  APEX  to  save  all  the  data  re¬ 
quired  to  restart  the  problem  where  it  was  terminated.  Other 
available  options  are  described  in  the  APEX  Reference  Manual 
furnished  by  CDC. 

Use  of  an  APEX  "control  program"  allows  greater  flexi¬ 
bility  and  control  of  the  APEX  solution  system.  The  example 
in  Table  8  shows  one  way  in  which  it  was  used  during  the 
test  program.  "RPOBBND"  is  the  lower  bound  on  the  objective 
function  and  places  a  bound  on  many  of  the  branches  APEX 
must  explore  in  solving  the  mixed  integer  problem.  The 
solution  to  the  problem,  as- determined  by  RAM/VM  and  RAM/GP, 
was  input  in  the  "control  program"  as  "RPOBBND"  to  limit  the 
number  of  branches  APEX  needed  to  consider.  For  minimization 
problems,  the  value  of  "RPOBBND"  is  complemented  (-) .  The 
"control  program"  also  selects  the  mixed  integer  option 
(MIXINT)  and  directs  APEX  to  write  the  output  into  a  file, 
defined  here  as  TEMP. 
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2 .  Representation  of  Decision  Variables 

We  used  two  approaches  in  setting  up  the  problem  in  the 
proper  format  for  APEX  to  handle  the  constraints: 


I  X.  <  1  k=l ,NGR 

XieGRk  1  " 

and  Xi  e  {0,1}  Vi  i=l,NVAR 

One  approach  was  to  declare  the  0-1  variables  as  bivalent 
variables;  the  other  was  to  use  special  ordered  sets.  When 
using  bivalent  variables,  all  0-1  variables  must  be  declared 
in  the  bounds  section  of  the  input  data.  The  equations 
establishing  the  mutually  exclusive  group  must  be  of  the 
less-than-or-equal-to  type,  as  declared  in  the  rows  section. 

To  use  special  ordered  sets,  an  additional  variable  must  be 
added  to  each  mutually  exclusive  group.  (These  added  variables 
are  labeled  ISC  and  2SC  in  Table  6.)  The  constraint  then 
becomes  an  equal-to  type,  and  APEX  must  select  exactly  one 
variable  from  each  mutually  exclusive  group.  The  appearance 
of  the  added  variable  in  the  solution  means  that  its  associ¬ 
ated  mutually  exclusive  group  is  not  represented  in  the 
solution.  Although  use  of  the  special  ordered  sets  requires 
that  additional  variables  be  included  in  the  problems,  we 
found  that  APEX  generally  solves  the  problems  more  efficiently 
when  they  are  structured  as  special  ordered  sets  than  when 
they  are  set  up  with  bivalent  variables.  Therefore,  most 
problems  solved  during  the  test  program  used  the  special 
ordered  sets. 
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